História do Unix e Linux: de 1969 até hoje

A história do Unix e do Linux, em resumo

A história do Unix e do Linux é uma longa disputa sobre quem pode ser proprietário do código-fonte. O Unix começou nos Bell Labs em 1969. O Linux começou em Helsínquia em 1991 e não partilha nenhum código original com o Unix. O que passou de um para o outro foi um modelo de conceção e um conjunto de interfaces publicadas: ficheiros, processos, pipes e uma shell que combina pequenos programas. O Unix espalhou-se pelas universidades na década de 1970 porque um acordo antitrust de 1956 impediu a AT&T (American Telephone and Telegraph) de vender software. Por isso, os Bell Labs licenciaram o código-fonte a baixo custo. O Unix acabou por estar presente em todo o lado, embora pertencesse à AT&T e a mais ninguém. As disputas de licenciamento que se seguiram determinaram qual sistema livre semelhante ao Unix acabaria no seu rack de servidores.

1969: um PDP-7 descartado e as ideias que permaneceram

Os Bell Labs saíram do projeto Multics em 1969. Multics (multiplexed information and computing service) era um grande sistema de time-sharing desenvolvido com o MIT e a General Electric, mas os Labs decidiram que era demasiado grande para ser concluído. Ken Thompson manteve as ideias de que gostava e abandonou as restantes, escrevendo um pequeno sistema de time-sharing num minicomputador PDP-7 descartado. Dennis Ritchie juntou-se a ele. O nome Unix era uma piada à custa do Multics.

Em 1970, o sistema foi transferido para um PDP-11 que os Labs compraram para os datilógrafos do departamento de patentes, porque era mais fácil financiar uma ferramenta de processamento de texto do que um sistema operativo. Essa máquina tinha 24 KB de memória de núcleo, dividida entre o sistema e os programas dos utilizadores. Esse acaso no financiamento explica por que o primeiro manual do Unix, datado de novembro de 1971, era um conjunto de documentos formatados, e também por que ainda se escreve man 5 crontab. Os números das secções desse manual são os mesmos das suas.

Duas alterações tornaram o desenho permanente. Os pipes chegaram na Version 3, em 1973, porque Doug McIlroy defendia há anos que devia ser possível ligar programas ponta a ponta, e Thompson adicionou o operador | para que a saída de um programa se tornasse a entrada do programa seguinte. Depois, a Version 4, ainda em 1973, foi reescrita em C. Um sistema operativo escrito numa linguagem portátil pode ser transferido para hardware para o qual não foi originalmente desenvolvido, e foi por isso que o Unix sobreviveu a todas as máquinas em que começou.

Por que o Unix se espalhou: a AT&T não podia vendê-lo

Um decreto de consentimento de 1956 encerrou um processo antitruste contra a AT&T. A AT&T manteve o seu monopólio telefónico e aceitou uma limitação em troca: não atuaria em negócios fora das telecomunicações. O software era um desses negócios. Por isso, quando as universidades pediram o Unix, a Bell Labs não podia vendê-lo como produto. A empresa licenciava o código-fonte por uma taxa nominal, sem suporte e sem garantia.

O efeito foi grande e não era o que a AT&T tinha planeado. O Sixth Edition Unix, lançado em 1975, chegou a centenas de departamentos de ciência da computação com o código-fonte completo. John Lions, da University of New South Wales, imprimiu o código-fonte do kernel com um comentário linha a linha e ensinou a partir dele. Uma geração aprendeu como funciona um sistema operativo lendo um sistema real.

Depois, a licença mudou. A licença da Seventh Edition, de 1979, proibia o uso do código-fonte em aulas, por isso o comentário de Lions circulava como fotocópias de fotocópias. Esta é a essência de toda a história. O Unix estava em todo o lado e não era livre ao mesmo tempo, portanto cada melhoria feita por alguém era uma melhoria no código proprietário de outra pessoa.

Berkeley: as partes do Unix que você realmente digita

Ken Thompson passou o ano letivo de 1975 a 1976 na University of California, Berkeley, e deixou para trás um grupo Unix muito ativo. O Computer Systems Research Group (CSRG) de Berkeley lançou tapes com melhorias locais, e essas tapes deram origem ao BSD, a Berkeley Software Distribution. Bill Joy escreveu grande parte do trabalho inicial: 1BSD em 1978 e, depois, 2BSD em 1979, que incluía o editor vi e o C shell.

É do C shell que vêm !! e !$. O Bash herdou essa sintaxe. É por isso que a expansão do histórico do bash ainda surpreende quem digita um ponto de exclamação entre aspas duplas mais de quarenta anos depois.

A DARPA (Defense Advanced Research Projects Agency dos EUA) pagou então a Berkeley para integrar os novos protocolos da internet no Unix. O 4.2BSD, lançado em agosto de 1983, incluía TCP/IP (transmission control protocol over internet protocol) e a interface de programação de aplicações de sockets. Todos os serviços de rede no seu servidor ainda chamam socket(), bind(), listen() e accept() nessa ordem, porque Berkeley escolheu esses nomes em 1983.

Um detalhe decidiu a década seguinte. Uma tape do BSD não era um sistema completo. Era um conjunto de adições ao Unix da AT&T, e era necessária uma licença válida do código-fonte da AT&T para executá-lo legalmente. Berkeley substituiu as partes da AT&T pelo seu próprio código ao longo de vários anos, ficheiro a ficheiro. A questão de saber se essa substituição ficou realmente completa acabou por chegar aos tribunais.

1984: a fragmentação e, depois, as guerras do Unix

O Bell System foi fragmentado em 1 January 1984, e o decreto de consentimento que mantinha a AT&T fora do negócio de software deixou de vigorar. A AT&T podia agora vender Unix como produto, e vendeu. As licenças comerciais do código-fonte ficaram caras, por isso o Unix deixou de ser algo barato que uma universidade entregava aos estudantes.

Os fabricantes já tinham criado variantes incompatíveis. Cada empresa de workstations distribuía o seu próprio Unix no seu próprio hardware. Assim, no final da década de 1980, um programa escrito para uma plataforma precisava de ser portado para a seguinte. Em 1988, o setor dividiu-se em dois grupos de normas: a Open Software Foundation, de um lado, e a Unix International, do outro. Durante anos, distribuíram sistemas incompatíveis enquanto discutiam qual Unix era o verdadeiro.

O POSIX (portable operating system interface) surgiu desse cenário. A norma IEEE 1003.1 foi publicada em 1988 e especificou o que um sistema semelhante ao Unix tinha de fazer: as chamadas de sistema, o comportamento da shell, os utilitários padrão e as interfaces da biblioteca C. Isto é mais importante do que parece, porque uma norma é uma especificação e nenhuma licença a abrange. Três anos depois, um estudante escreveu um kernel com base nesses documentos.

Minix e o espaço que deixou

Andrew Tanenbaum lançou o Minix em 1987 como sistema didático para o seu livro sobre sistemas operativos. O Minix era um sistema pequeno, semelhante ao Unix. O código-fonte vinha com o livro e funcionava nos PCs baratos que os estudantes realmente tinham. Era permitido analisá-lo numa sala de aula, ao contrário do Unix Seventh Edition.

O Minix manteve-se pequeno de propósito, porque tinha de poder ser explicado num livro. Tanenbaum recusou patches que o teriam transformado num sistema adequado para produção. A licença também não era livre: era necessário comprar o livro, e a redistribuição de uma versão modificada do Minix não dependia apenas de si. Assim, em 1991, um estudante podia ler um kernel semelhante ao Unix em funcionamento, mas não podia construir nada duradouro sobre ele.

O GNU tinha tudo, exceto um kernel

Richard Stallman anunciou o projeto GNU em setembro de 1983, com o objetivo de criar um sistema completo, livre e semelhante ao Unix. Em 1991, o GNU tinha produzido a maior parte dos componentes que envolvem um kernel: o compilador GCC, a biblioteca C do GNU, os utilitários binários e o bash, a shell que Brian Fox escreveu em 1989 e na qual o seu servidor ainda o inicia. O kernel GNU, o Hurd, era o componente cujo lançamento continuava a ser adiado.

A GNU General Public License versão 2 foi publicada em junho de 1991. A sua regra é simples. Pode utilizar e alterar o código. Se distribuir o resultado, tem de distribuir também o código-fonte nos mesmos termos. Essa regra será o ponto central desta história daqui a duas secções.

Agosto de 1991: a mensagem para comp.os.minix

Em 25 de agosto de 1991, um estudante de Helsínquia publicou uma mensagem no grupo Usenet comp.os.minix:

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.

A versão 0.01 foi lançada em setembro de 1991. Não partilhava código nem com Unix nem com Minix. Era um kernel novo para o 386, desenvolvido numa máquina com Minix, escrito com base nas interfaces POSIX e combinado com as ferramentas GNU que já existiam. Em janeiro de 1992, Tanenbaum disse a Torvalds que um kernel monolítico era um projeto obsoleto. A crítica ao projeto tinha fundamento, mas Torvalds estava a responder a uma pergunta diferente: o que funciona bem no único computador barato que um estudante possui.

Em fevereiro de 1992, a versão 0.12 passou a ser licenciada ao abrigo da GPL. Desde então, Torvalds referiu essa decisão como a sua melhor decisão. A licença original do Linux proibia qualquer troca de dinheiro, o que teria impedido os fornecedores de CD e as empresas de suporte que surgiram depois. A GPL permitiu o comércio e, ao mesmo tempo, obrigou a que todas as alterações distribuídas regressassem à mesma árvore partilhada.

O processo: abril de 1992 a fevereiro de 1994

A Berkeley lançou o Networking Release 2 (Net/2) em junho de 1991: um sistema BSD quase completo, com os ficheiros derivados do AT&T removidos. Faltavam seis ficheiros do kernel. Bill e Lynne Jolitz escreveram substitutos e lançaram o 386BSD 0.0 em março de 1992 e, depois, o 386BSD 0.1 em 14 de julho de 1992. Passou a existir um BSD gratuito, completo e maduro para o 386, enquanto o Linux ainda era apenas um kernel desenvolvido como passatempo. A Berkeley Software Design, Inc. (BSDi) vendia uma compilação comercial com suporte, o BSD/386, e publicitava-a com o número de telefone 1-800-ITS-UNIX.

Em abril de 1992, a Unix System Laboratories (USL), a subsidiária da AT&T que então detinha o Unix, processou a BSDi num tribunal federal de New Jersey por segredos comerciais e pela marca Unix. Mais tarde, a ação foi alterada para incluir também os Regents of the University of California. A Universidade apresentou uma ação reconvencional na Califórnia em 1993, argumentando que a AT&T tinha distribuído código da Berkeley dentro do System V sem o crédito exigido pela sua própria licença.

O núcleo jurídico do caso desagregou-se em 1993. O juiz Dickinson Debevoise recusou à USL uma providência cautelar, considerando que a alegação de copyright da USL sobre o código antigo do 32V era provavelmente inválida, porque a AT&T tinha distribuído esse código durante anos sem avisos de copyright. A Novell comprou a USL à AT&T em meados de 1993, e a administração da Novell queria terminar o conflito. O caso foi resolvido em fevereiro de 1994. Dos cerca de 18,000 ficheiros da distribuição da Berkeley, três foram removidos e cerca de setenta receberam avisos de copyright da USL.

A Berkeley lançou o 4.4BSD-Lite em junho de 1994, e este estava juridicamente limpo. O FreeBSD e o NetBSD, ambos fundados em 1993 com base no código contestado do Net/2, tiveram então de reconstruir os seus sistemas sobre a nova base, processo que ocupou a maior parte do resto de 1994. O Linux 1.0 foi lançado em março de 1994, a meio dessa reconstrução.

Por que o Linux conquistou os servidores, e não o BSD?

A ação judicial é a resposta mais conhecida, e faz parte da explicação. Entre abril de 1992 e fevereiro de 1994, quem escolhesse um Unix livre para um produto tinha de ponderar uma reivindicação ativa dos advogados da AT&T contra um kernel criado por um estudante finlandês, sobre o qual ninguém podia processá-lo. Essa foi precisamente a janela em que a web chegou e em que surgiram as primeiras distribuições Linux: Slackware em julho de 1993, Debian em agosto de 1993 e, depois, Red Hat e SUSE.

Quatro outros fatores foram tão importantes quanto o processo judicial.

• Hardware. O Linux tinha como alvo o PC 386 comum desde a primeira linha de código, e esse foi o hardware que ficou barato. O centro de gravidade do BSD estava no VAX e nas workstations, e a portabilidade para 386 foi um esforço externo de duas pessoas.
• A licença. A GPL exige que uma empresa que distribua um kernel modificado publique as suas alterações, pelo que o trabalho dos fornecedores regressava à mesma árvore de código. A licença BSD permite que uma empresa mantenha as suas alterações privadas, e foi isso que as empresas fizeram.
• O modelo de desenvolvimento. Torvalds integrava rapidamente patches de pessoas desconhecidas e fazia lançamentos constantes. O 386BSD lançava versões com lentidão suficiente para que os próprios utilizadores criassem dois forks em 1993, o NetBSD e o FreeBSD, e outro no OpenBSD em 1995.
• O efeito de rede. Os programadores vão para onde os outros programadores já estão, e os drivers são desenvolvidos para o sistema que tem mais utilizadores.

É importante ser rigoroso quanto à questão técnica. Em 1994, o BSD era o sistema mais acabado, com uma base coerente, um histórico documentado e código de rede ao qual o Linux levou anos a chegar. Ninguém escolheu o Linux em 1994 por ser melhor. Escolheram-no porque estava disponível, não tinha restrições legais, funcionava no hardware que já possuíam e melhorava todas as semanas.

O que o BSD preservou e onde é executado atualmente

O BSD continuou a ser desenvolvido. O que perdeu foi a posição padrão. A evidência mais clara está na sua própria máquina: o projeto OpenBSD criou o OpenSSH em 1999, e ele é o servidor SSH em quase todos os sistemas Linux lançados atualmente. Por isso, os hábitos de utilização de chaves SSH que vale a pena aprender são idênticos nas duas famílias.

A Netflix distribui vídeo a partir de appliances FreeBSD. O Junos, o sistema operativo dos routers Juniper, utiliza FreeBSD na base. O software de sistema da PlayStation deriva do FreeBSD. O macOS e o iOS da Apple incluem código BSD no kernel e em todo o userland. A licença permissiva que fez o BSD perder a árvore de servidores partilhada colocou código BSD em muitos equipamentos que nunca o mencionam.

Se está a escolher atualmente, a questão é prática, não histórica. Comparar Linux e FreeBSD como servidor resume-se ao ZFS, às jails, à árvore de ports e à quantidade de software de terceiros que assume a existência de Linux na base. O FreeBSD 15 como servidor é um sistema atual e mantido, não uma peça de museu. E Linux versus Windows Server é uma questão separada, cuja resposta depende da sua stack de aplicações.

O design de 1969 que você usa hoje em um VPS

Cada um destes elementos é mais antigo do que a maioria das pessoas que os utiliza.

• O pipe. who | wc -l conta os usuários conectados porque o Unix Version 3, em 1973, permitia que a saída de um programa se tornasse a entrada de outro.
• As seções do manual. man 1 ls e man 5 crontab usam o esquema de numeração do manual de novembro de 1971.
• A divisão do filesystem. /usr existe porque o disco raiz daquele PDP-11 ficou cheio em 1971, e os desenvolvedores moveram os arquivos para o segundo conjunto de discos. Desde então, as distribuições desfizeram a divisão: execute ls -ld /bin no Ubuntu 24.04 ou no Debian 13 e você obterá um link simbólico para usr/bin.
• As chamadas de socket. A Berkeley as escreveu para o 4.2BSD em 1983, e todo daemon de rede ainda as utiliza.
• POSIX. Um script #!/bin/sh escrito de acordo com o padrão é executado sem alterações no Linux, no FreeBSD, no macOS e no Solaris, porque o padrão é o elemento que todos eles implementaram.

Quando você aluga um servidor privado virtual e faz login, está digitando em uma interface projetada para uma máquina com 24 KB de memória e um departamento de patentes para atender. Ela sobreviveu porque a interface foi publicada, discutida, padronizada e depois reimplementada do zero por pessoas que nunca tiveram permissão para ver o código original.

FAQ

O Linux contém algum código original do Unix?

Não. Linus Torvalds escreveu o kernel do zero a partir de 1991, tendo como objetivo as interfaces POSIX, e não qualquer código-fonte da AT&T. A herança do Unix está no design e numa interface publicada: ficheiros, processos, pipes e os nomes das chamadas de sistema. As ferramentas GNU em torno do kernel também foram escritas do zero, a partir de 1983. Essa independência é a razão pela qual o processo judicial da AT&T sobre o código do BSD nunca afetou o Linux.

Quando ocorreu o processo da AT&T contra o BSD e ele eliminou o BSD?

A USL, subsidiária da AT&T que detinha o Unix, processou a BSDi em abril de 1992 e posteriormente acrescentou a University of California como ré. Em 1993, o juiz recusou uma providência cautelar, considerando provável que a reivindicação de copyright sobre o código mais antigo do 32V fosse inválida. A Novell comprou a USL em meados de 1993 e chegou a um acordo em fevereiro de 1994. Foram removidos três ficheiros de cerca de 18,000 e aproximadamente setenta receberam novos avisos de copyright. O processo não eliminou o BSD. Suspendeu a adoção do BSD durante os dois anos em que o mundo estava a escolher um Unix livre.

Por que motivo o Linux substituiu o BSD nos servidores?

A segurança jurídica foi uma das razões: durante 1992 e 1993, o Linux não enfrentava nenhum processo e o BSD enfrentava um. As outras foram o 386 como plataforma-alvo desde o primeiro dia, a GPL, que fazia regressar as alterações dos fornecedores a uma única árvore de código, e um processo de integração suficientemente rápido para manter o interesse dos contribuidores enquanto o 386BSD se dividia em três projetos. O mérito técnico não foi o fator decisivo, porque o BSD era o sistema mais completo em 1994.

Ainda vale a pena executar FreeBSD atualmente?

Sim, por razões concretas: ZFS integrado no sistema base, jails como modelo de isolamento maduro, um sistema base desenvolvido como uma unidade coerente e documentação que se mantém correta. O custo é o trabalho de compatibilidade, porque a maioria dos softwares de servidor de terceiros, das ferramentas de contentores e do suporte dos fornecedores pressupõe Linux. Escolha FreeBSD quando as suas capacidades de armazenamento e rede justificarem esse custo, e não por lealdade à linhagem mais antiga.