A parábola de UNIX

Uma narrativa sobre simplicidade, poder e administração de sistemas

1. Antes do UNIX: quando o sistema era maior que o programador (1960–1969)

No final da década de 1960, sistemas operacionais eram grandes, rígidos e escritos para máquinas específicas. Projetos como o Multics (MIT, Bell Labs, General Electric) tentavam criar um sistema “perfeito”: seguro, multiusuário, hierárquico.

O problema?

➡️ Complexidade excessiva

➡️ Ciclo de desenvolvimento lento

➡️ Pouca portabilidade

Do Multics, ficaram duas lições fundamentais:

  • Sistemas grandes demais não evoluem bem
  • A simplicidade é uma virtude arquitetural

Foi nesse cenário que três nomes entram na história:

  • Ken Thompson
  • Dennis Ritchie
  • Brian Kernighan

Bell Labs decide abandonar o Multics. Ken Thompson decide recomeçar do zero.

2. 1969–1971: UNIX nasce pequeno, interativo e humano

Ken Thompson escreve o primeiro UNIX em assembly, rodando em um PDP-7.

As ideias centrais já estavam lá:

  • Um kernel pequeno
  • Processos simples
  • Arquivos como abstração universal
  • Ferramentas pequenas que fazem uma coisa bem

Aqui nasce o primeiro paradigma UNIX:

“Tudo é um arquivo”

Isso não era filosofia — era engenharia prática.

Arquivos, dispositivos, terminais, tudo expunha a mesma interface:

int fd = open("/dev/tty", O_RDWR);
write(fd, "hello\n", 6);

O terminal era apenas outro arquivo.

➡️ Isso simplificou drasticamente o kernel ➡️ Criou uma interface uniforme para usuários e programas ➡️ Plantou a semente do que hoje chamamos POSIX

3. 1972–1973: nasce a linguagem C — o elo perdido

Escrever um sistema inteiro em assembly não escala.

Dennis Ritchie então evolui a linguagem B para algo novo: C.

C foi projetada com objetivos muito claros:

  • Ser próxima do hardware
  • Mas portável
  • Sem esconder o custo das operações

UNIX foi reescrito em C em 1973 — algo revolucionário.

Pela primeira vez:

Um sistema operacional não estava preso a uma arquitetura

Exemplo de como C reflete essa mentalidade:

char buffer[128];
int n = read(0, buffer, sizeof(buffer));
write(1, buffer, n);

Sem objetos mágicos. Sem runtime pesado. Você controla memória, I/O, fluxo.

Esse código ainda compila hoje. Esse é o poder da decisão.

4. Processos, fork e o modelo mental UNIX

Outro paradigma central nasce cedo:

Processos são baratos

O UNIX introduz fork() como primitiva central.

pid_t pid = fork();

if (pid == 0) {
    execl("/bin/ls", "ls", NULL);
} else {
    wait(NULL);
}

Aqui surgem vários conceitos que todo sysadmin vive diariamente:

  • Processos pais e filhos
  • Substituição de imagem (exec)
  • Isolamento simples
  • Shell como orquestrador de processos

O shell não é especial. Ele apenas usa as mesmas syscalls que você usa em C.

5. Pipes: compondo programas como Lego (1973–1975)

Talvez o maior salto conceitual do UNIX:

Programas pequenos, conectados por streams

O pipe (|) nasce como consequência direta de fork(), read() e write().

int fd[2];
pipe(fd);

if (fork() == 0) {
    dup2(fd[1], 1); // stdout
    execlp("ls", "ls", NULL);
} else {
    dup2(fd[0], 0); // stdin
    execlp("wc", "wc", "-l", NULL);
}

Isso explica por que ferramentas UNIX são simples:

  • grep filtra
  • awk transforma
  • sed edita
  • wc conta

Elas não precisam saber de tudo.

Para administração de sistemas, isso significa:

  • Logs são streams
  • Monitoramento é encadeamento
  • Automação é composição

6. Arquivos, permissões e o nascimento do modelo de segurança

UNIX precisava ser multiusuário.

Surge então um modelo simples e poderoso:

  • UID
  • GID
  • Permissões rwx
struct stat st;
stat("arquivo", &st);

if (st.st_mode & S_IRUSR) {
    // dono pode ler
}

Nada de ACLs complexas inicialmente. A regra era:

Segurança simples é segurança auditável

Esse modelo sobrevive até hoje em Linux, BSD, AIX, Solaris.

Sysadmins vivem disso:

  • chmod
  • chown
  • umask

Tudo mapeia diretamente para chamadas POSIX.

7. 1980–1988: UNIX se fragmenta — nasce o problema

Com o sucesso do UNIX:

  • BSD (Berkeley)
  • System V (AT&T)
  • AIX, HP-UX, Solaris

Cada um evolui diferente.

O problema surge:

➡️ Código não portável

➡️ Scripts quebram

➡️ Syscalls mudam

A comunidade precisava de um contrato comum.

8. POSIX: padronizar sem matar a alma (1988–)

POSIX não define como o sistema funciona internamente. Ele define o que deve existir.

Exemplos:

  • fork()
  • exec()
  • open(), read(), write()
  • Sinais
  • Threads (pthreads)
  • Shell behavior

Exemplo clássico POSIX:

#include <unistd.h>

sysconf(_SC_PAGESIZE);
sysconf(_SC_NPROCESSORS_ONLN);

Isso permite que:

  • Linux
  • BSD
  • AIX
  • macOS
  • Solaris

Executem o mesmo código fonte.

Para administração de sistemas, POSIX garante:

  • Scripts portáveis
  • Ferramentas previsíveis
  • Comportamento consistente

9. O impacto direto na vida do sysadmin moderno

Quando você:

  • Usa ps, top, htop
  • Analisa /proc
  • Encadeia grep | awk | sed
  • Depura com strace
  • Controla serviços

Você está vivendo decisões feitas nos anos 70.

Até containers seguem o mesmo modelo:

  • Namespaces → processos
  • Cgroups → recursos
  • Filesystems → abstração

Nada disso seria possível sem UNIX + C + POSIX.

10. Conclusão: UNIX não é velho — é maduro

UNIX não venceu por ser bonito. Venceu porque foi honesto.

  • C não promete segurança automática
  • UNIX não promete mágica
  • POSIX não promete inovação rápida

Eles prometem algo mais raro:

Compreensão

E quem compreende o sistema:

  • administra melhor
  • automatiza melhor
  • depura melhor
  • constrói sistemas mais confiáveis

Essa é a herança.

Ken Thompson Dennis Ritchie Brian Kernighan

Eles não criaram apenas um sistema. Criaram uma forma de pensar sistemas.


Minha mais simples matemática: Conhecimento dividido é poder multiplicado!