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 do código original do 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 proibiu a AT&T (American Telephone and Telegraph) de vender software. Por isso, os Bell Labs licenciavam o código-fonte a baixo custo. O Unix acabou por estar presente em todo o lado, embora continuasse a pertencer à AT&T. As disputas de licenciamento que se seguiram determinaram qual sistema Unix-like livre acabaria no rack dos seus servidores.

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

A Bell Labs abandonou o projeto Multics em 1969. Multics (multiplexed information and computing service) era um sistema de time-sharing de grande dimensão, desenvolvido com o MIT e a General Electric. Os Laboratórios concluíram que era demasiado grande para ser terminado. Ken Thompson manteve as ideias de que gostava e abandonou as restantes. Escreveu 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 Laboratórios 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 principal, dividida entre o sistema e os programas dos utilizadores. Esse acaso no financiamento explica por que razão o primeiro manual do Unix, datado de novembro de 1971, era um conjunto de documentos formatados. Também explica por que razão ainda escreve man 5 crontab. Os números das secções desse manual são os números das secções do seu manual.

Duas alterações tornaram o design permanente. Os pipes chegaram na Version 3, em 1973, porque Doug McIlroy defendia há anos que devia ser possível ligar programas de ponta a ponta. Thompson acrescentou o operador |, para que a saída de um programa passasse a ser a entrada do programa seguinte. Depois, a Version 4, mais tarde 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 escrito. É 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 resolveu um processo antitrust contra a AT&T. A AT&T manteve o monopólio telefónico e aceitou uma limitação em troca: ficaria fora de negócios que não fossem de telecomunicações. O software era um desses negócios. Por isso, quando as universidades pediram o Unix, os Bell Labs não podiam vendê-lo como produto. Licenciaram 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 Unix Sixth Edition, lançado em 1975, chegou a centenas de departamentos de informática 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 do Seventh Edition, em 1979, proibia o uso do código-fonte nas aulas, pelo que 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, por isso cada melhoria feita por alguém era uma melhoria ao código proprietário de outra pessoa.

Berkeley: as partes do Unix que você realmente escreve

Ken Thompson passou o ano académico 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 distribuía fitas com melhorias locais, e essas fitas deram origem ao BSD, 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 a C shell.

A C shell é a origem de !! e !$. O Bash herdou essa sintaxe. Por isso, a expansão do histórico do bash ainda surpreende quem escreve um ponto de exclamação entre aspas duplas mais de quarenta anos depois.

A DARPA (US Defense Advanced Research Projects Agency) pagou então a Berkeley para integrar os novos protocolos da internet no Unix. A 4.2BSD, lançada 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 continuam a chamar socket(), bind(), listen() e accept() nessa ordem, porque Berkeley escolheu esses nomes em 1983.

Um detalhe determinou a década seguinte. Uma fita 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 a executar legalmente. Ao longo de vários anos, Berkeley substituiu as partes da AT&T pelo seu próprio código, ficheiro a ficheiro. A questão de saber se essa substituição estava realmente completa acabou por chegar aos tribunais.

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

O Bell System foi desmembrado em 1 de janeiro de 1984, e o decreto de consentimento que mantinha a AT&T fora do negócio de software deixou de vigorar com ele. A AT&T passou a poder vender o Unix como produto, e foi isso que fez. 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 fornecedores já tinham criado variantes incompatíveis. Cada empresa de estações de trabalho distribuía o seu próprio Unix no seu próprio hardware. No final da década de 1980, um programa escrito para um sistema precisava de ser portado para o seguinte. Em 1988, o setor dividiu-se em dois grupos de normalização: a Open Software Foundation, de um lado, e a Unix International, do outro. Durante anos, distribuíram sistemas incompatíveis enquanto discutiam qual deles era o Unix verdadeiro.

O POSIX (portable operating system interface) surgiu dessa situação. A norma IEEE 1003.1 foi publicada em 1988 e especificou o que um sistema semelhante ao Unix deve 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 a lacuna que deixou

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

O Minix manteve-se pequeno de propósito, porque tinha de ser explicado num livro. Tanenbaum recusou patches que o teriam transformado num sistema de produção. A licença também não era livre: era necessário comprar o manual, e a redistribuição de uma versão modificada do Minix não dependia apenas de si. Assim, em 1991, um estudante podia estudar um kernel semelhante ao Unix em funcionamento, mas não podia construir algo 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 e livre semelhante ao Unix. Em 1991, o GNU já tinha produzido a maioria dos componentes que rodeiam 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 que o seu servidor ainda inicia para si. O kernel do GNU, o Hurd, era o componente que continuava a atrasar-se.

A GNU General Public License versão 2 foi publicada em junho de 1991. A regra é curta. Pode utilizar e alterar o código e, se distribuir o resultado, tem de distribuir o código-fonte sob os mesmos termos. Essa regra torna-se o ponto central desta história daqui a duas secções.

Agosto de 1991: a publicação no comp.os.minix

Em 25 de agosto de 1991, um estudante de Helsínquia publicou 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 para as 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. Tinha um argumento válido sobre o projeto, 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 foi relicenciada ao abrigo da GPL. Desde então, Torvalds chamou a essa decisão a sua melhor decisão. A licença original do Linux proibia qualquer transação financeira, o que teria impedido os fornecedores de CD e as empresas de suporte que surgiram depois. A GPL permitia o comércio e, ao mesmo tempo, obrigava a integrar todas as alterações distribuídas na mesma árvore partilhada.

O processo judicial: 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 livre, completo e maduro para o 386, no mesmo momento em que o Linux ainda era um kernel desenvolvido como passatempo. A Berkeley Software Design, Inc. (BSDi) vendia uma versão comercial com suporte, o BSD/386, e anunciava-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. O processo foi posteriormente alterado para incluir também os Regents of the University of California. A Universidade apresentou uma ação reconvencional na Califórnia em 1993, alegando 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.

A base jurídica do processo desmoronou em 1993. O juiz Dickinson Debevoise recusou à USL uma providência cautelar, considerando que a sua alegação de copyright sobre o código mais 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 encerrar o conflito. O processo 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, o que ocupou a maior parte do restante de 1994. O Linux 1.0 foi lançado em março de 1994, durante essa reconstrução.

Por que o Linux ficou com 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 avaliar uma reivindicação ativa dos advogados da AT&T contra um kernel criado por um estudante finlandês que ninguém podia processar. Essa foi exatamente 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. A Red Hat transformou essa vantagem inicial no padrão comercial, e o percurso do Red Hat Linux ao CentOS e depois ao Rocky e ao AlmaLinux explica por que uma distribuição fundada em 1993 ainda determina o que corre em muitos servidores empresariais.

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

• Hardware. O Linux teve 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 era o VAX e a workstation, e a portabilidade para 386 foi um esforço externo de duas pessoas.
• A licença. A GPL obriga uma empresa que distribua um kernel modificado a publicar as suas alterações, fazendo com que o trabalho dos fornecedores regressasse a uma única árvore. A licença BSD permite que uma empresa mantenha as suas alterações privadas, e as empresas fizeram isso.
• O modelo de desenvolvimento. Torvalds integrava rapidamente patches de pessoas desconhecidas e fazia releases constantes. O 386BSD fazia releases com lentidão suficiente para que os próprios utilizadores criassem dois forks em 1993, o NetBSD e o FreeBSD, e outro fork em 1995, o OpenBSD.
• O impulso acumulado. Os developers vão para onde os outros developers já estão, e os drivers são desenvolvidos para o sistema que tem mais utilizadores.

É preciso ser rigoroso quanto à questão técnica. Em 1994, o BSD era o sistema mais completo, 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 porque era melhor. Escolheram-no porque estava disponível, não tinha restrições legais, corria no hardware que já possuíam e melhorava todas as semanas.

O que o BSD preservou e onde é executado atualmente

O BSD continuou a desenvolver-se. 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 este é o servidor SSH presente em quase todos os sistemas Linux lançados atualmente. Por isso, os hábitos de chaves SSH que vale a pena aprender são idênticos nas duas famílias.

A Netflix distribui vídeo a partir de dispositivos FreeBSD. O Junos, o sistema operativo dos routers Juniper, é baseado em FreeBSD. O software de sistema da PlayStation deriva do FreeBSD. O macOS e o iOS da Apple incluem código BSD no kernel e em grande parte do userland. A licença permissiva que impediu o BSD de manter a árvore partilhada de servidores 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 pressupõe Linux como base. FreeBSD 15 como servidor é um sistema atual e mantido, não uma peça de museu. E Linux contra Windows Server é uma questão separada, cuja resposta depende da sua stack de aplicações.

O design de 1969 que utiliza atualmente numa VPS

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

• O pipe. who | wc -l conta os utilizadores com sessão iniciada porque o Version 3 Unix, em 1973, permitia que a saída de um programa se tornasse a entrada de outro.
• As secções do manual. man 1 ls e man 5 crontab utilizam o esquema de numeração do manual de novembro de 1971.
• A divisão do sistema de ficheiros. /usr existe porque o disco raiz daquele PDP-11 ficou cheio em 1971 e os programadores moveram os ficheiros 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 obterá uma ligação simbólica para usr/bin.
• As chamadas de socket. A Berkeley escreveu-as para o 4.2BSD em 1983, e todos os daemons de rede continuam a utilizá-las.
• POSIX. Um script #!/bin/sh escrito de acordo com a norma é executado sem alterações no Linux, no FreeBSD, no macOS e no Solaris, porque a norma é o elemento que todos implementaram.

Uma herança não sobreviveu à transição: a sequência de arranque baseada em shell scripts que o Linux herdou do System V desapareceu agora de quase todas as distribuições, e o argumento que a substituiu pelo systemd é o conflito mais recente sobre o que deve ser um sistema semelhante ao Unix.

Quando aluga um servidor privado virtual e inicia sessão, está a escrever numa interface concebida para uma máquina com 24 KB de memória e um departamento de patentes para servir. Essa interface sobreviveu porque foi publicada, debatida, normalizada e depois reimplementada de raiz por pessoas que nunca tiveram autorizaçã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 alvo 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 relacionado com código do BSD nunca afetou o Linux.

Quando foi o processo da AT&T contra o BSD e ele acabou com o BSD?

A USL, subsidiária da AT&T que detinha o Unix, processou a BSDi em April 1992 e mais tarde acrescentou a University of California como ré. Em 1993, o juiz recusou uma providência cautelar, considerando provavelmente inválida a alegação de direitos de autor sobre o código mais antigo do 32V. A Novell comprou a USL em meados de 1993 e resolveu o processo em February 1994, com a remoção de three ficheiros de cerca de 18,000 e a inclusão de novos avisos de direitos de autor em aproximadamente seventy. O processo não acabou com o BSD. A adoção do BSD ficou suspensa durante os dois anos em que o mundo escolhia um Unix livre.

Por que motivo o Linux conquistou os servidores em vez do BSD?

A segurança jurídica foi uma das razões: durante 1992 e 1993, o Linux não tinha nenhum processo judicial e o BSD tinha um. As outras foram o 386 como 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 three ramos. 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 utilizar 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 do software de servidor de terceiros, das ferramentas de contentores e do suporte dos fornecedores pressupõe Linux. Escolha FreeBSD quando as suas funcionalidades de armazenamento e rede justificarem esse custo, e não por lealdade à linhagem mais antiga.