O que é um sistema operacional? — Fundamentos de OS

O gerente invisível

Toda vez que você roda bin/rails server, algo gerencia os milhares de detalhes necessários para fazer tudo funcionar: alocando RAM para objetos Ruby, agendando tempo de CPU entre seu servidor e sua playlist do Spotify, lendo arquivos do disco e roteando pacotes de rede do navegador até o Puma.

Você nunca pediu a nada para fazer isso. O sistema operacional (SO) fez tudo, silenciosamente, nos bastidores.

Um sistema operacional é a camada de software entre suas aplicações e o hardware. É o gerente que garante que cada programa receba os recursos que precisa sem pisar nos outros programas.

flowchart TB
  APP["Suas aplicações<br/>Ruby · Chrome · VS Code · PostgreSQL"]
  OS["Sistema operacional<br/>gerenciador de processos · gerenciador de memória · sistema de arquivos<br/>drivers de dispositivo · pilha de rede · segurança"]
  HW["Hardware<br/>CPU · RAM · SSD · placa de rede"]
  APP --> OS --> HW

Os cinco trabalhos de um SO

Todo sistema operacional (macOS, Linux, Windows) executa os mesmos cinco trabalhos principais:

1. Gerenciamento de processos

O SO decide quais programas rodam, quando rodam e quanto tempo de CPU cada um recebe. Seu computador pode ter mais de 200 processos rodando simultaneamente, mas apenas 8 núcleos de CPU: o SO faz o malabarismo.

2. Gerenciamento de memória

O SO aloca RAM para cada processo, protege processos de acessar a memória um do outro e lida com o que acontece quando a RAM enche (swap para o disco).

3. Gerenciamento do sistema de arquivos

O SO organiza dados no disco em arquivos e diretórios, gerencia permissões de leitura/escrita e administra acesso concorrente (dois programas escrevendo no mesmo arquivo).

4. Gerenciamento de dispositivos

O SO se comunica com o hardware através de drivers de dispositivo: teclado, mouse, tela, placa de rede, SSD. Aplicações nunca falam com o hardware diretamente.

5. Segurança e controle de acesso

O SO impõe quem pode ler, escrever ou executar arquivos. É por isso que chmod, permissões de arquivo e contas de usuário existem.

O kernel: o coração do SO

O kernel é o núcleo do sistema operacional. É o único software que roda com acesso total ao hardware, o chamado modo kernel (ring 0 em CPUs x86).

Todo o resto (Ruby, Chrome, PostgreSQL) roda em modo usuário (ring 3) com acesso restrito. Quando um programa em modo usuário precisa de acesso ao hardware (ler um arquivo, enviar um pacote de rede), ele faz uma chamada de sistema (system call) para o kernel.

flowchart TB
  U["Modo usuário (ring 3)<br/>Ruby, Chrome, Puma, PostgreSQL<br/>acesso restrito"]
  S["Chamadas de sistema (o portão)<br/>open(), read(), write(), fork(), exec(), socket()"]
  K["Modo kernel (ring 0)<br/>scheduler, gerenciador de memória, sistema de arquivos, drivers<br/>acesso total ao hardware"]
  H["Hardware"]
  U --> S --> K --> H

Chamadas de sistema são a única forma de programas do usuário interagirem com o hardware. Quando o Ruby executa File.read("data.csv"), ele dispara as chamadas de sistema open() e read(), que pedem ao kernel para acessar o disco em nome do Ruby.

macOS, Linux e Windows

Como dev Rails, você vai encontrar os três:

SO	Kernel	Onde Você Usa
macOS	XNU (Mach + BSD)	Sua máquina de desenvolvimento (MacBook)
Linux	Linux	Servidores de produção (Ubuntu, Debian, Alpine)
Windows	NT	WSL2 para desenvolvimento Rails

macOS e Linux são ambos Unix-like: compartilham os mesmos conceitos (processos, permissões de arquivo, pipes, sinais) e a maioria dos comandos do terminal funciona de forma idêntica. É por isso que o desenvolvimento Rails no macOS transfere perfeitamente para servidores Linux de produção.

O Windows é fundamentalmente diferente internamente, e é por isso que Rails no Windows usa WSL2 (Windows Subsystem for Linux): ele roda um kernel Linux real dentro do Windows.

Filosofia Unix

O Unix (o ancestral do macOS e Linux) foi construído sobre uma filosofia que você vai reconhecer em código Rails bem organizado:

"Faça uma coisa e faça bem feito."

Programas pequenos e focados que podem ser combinados
Texto como interface universal
Tudo é um arquivo

Você vê isso em como os comandos Unix funcionam:

# Cada comando faz UMA coisa — depois são combinados com pipes
cat server.log | grep "ERROR" | wc -l
#   ler arquivo    filtrar linhas  contar

A mesma ideia aparece em código Rails:

Responsabilidade Única: Cada classe faz uma coisa
Services e query objects pequenos: Um trabalho cada, combinados por quem chama
Limites DDD: Cada domínio cuida da sua própria responsabilidade

O que acontece quando você liga seu computador

O processo de boot revela como o SO assume o controle:

BIOS/UEFI: Firmware na placa-mãe roda primeiro, verifica o hardware
Bootloader (GRUB, systemd-boot): Carrega o kernel do disco para a RAM
Inicialização do kernel: O kernel configura gerenciamento de memória, drivers e o agendador de processos
Sistema init (systemd, launchd): O primeiro processo em modo usuário inicia: PID 1
Serviços iniciam: PostgreSQL, Nginx, SSH e outros daemons são lançados
Login: A interface gráfica ou terminal aparece

flowchart LR
  A["Ligar"] --> B["BIOS/UEFI"] --> C["Bootloader"] --> D["Kernel"] --> E["Init (PID 1)"] --> F["Serviços"] --> G["Login"]

O sistema init (PID 1) é o pai de todos os outros processos. No Linux, geralmente é o systemd. No macOS, é o launchd. Num servidor tradicional, o systemd mantém o Puma rodando e o reinicia se ele travar. Este app faz deploy com Kamal, então é o Docker que reinicia o container do app.

Vendo o SO em ação

Você pode observar o SO trabalhando agora mesmo:

# Quantos processos estão rodando?
ps aux | wc -l
# => 287 (típico para uma máquina de desenvolvimento)

# Quanta RAM está em uso?
free -h          # Linux
vm_stat          # macOS

# O que a CPU está fazendo?
top              # Monitor de processos em tempo real
htop             # Versão melhor (instale com brew/apt)

# Quais arquivos o Ruby tem abertos?
lsof -p $(pgrep -f "ruby")  # Listar arquivos abertos do processo Ruby

A partir do Ruby, você pode consultar o SO diretamente:

# ID do processo atual
Process.pid          # => 42731

# ID do processo pai
Process.ppid         # => 42700

# Número de núcleos da CPU
require 'etc'
Etc.nprocessors      # => 8

# Diretório de trabalho atual
Dir.pwd              # => "/Users/dev/myapp"

# Variáveis de ambiente (definidas pelo shell do SO)
ENV['HOME']          # => "/Users/dev"
ENV['PATH']          # => "/usr/local/bin:/usr/bin:..."
ENV['RAILS_ENV']     # => nil se não definida (aí Rails.env assume "development")

Por que devs Rails precisam entender o SO

Situação	Conhecimento de SO Necessário
Deploy em produção	Gerenciamento de processos Linux, systemd, permissões
Debugar vazamentos de memória	Gerenciamento de memória do SO, `ps`, `top`, swap
Configurar workers do Puma	Fork de processos, núcleos da CPU, memória por processo
Configurar PostgreSQL	I/O de arquivo, memória compartilhada (`shared_buffers`), Unix sockets
Lidar com upload de arquivos	Sistema de arquivos, diretórios temporários, permissões
Usar variáveis de ambiente	Shell, herança de processos, arquivos `.env`
Debugar "too many open files"	Descritores de arquivo, `ulimit`, limites do SO

O SO não é uma abstração que você pode ignorar. Toda app Rails roda em um SO, e bugs de produção frequentemente vivem na camada do SO.

Resumo

Conceito	O que Significa
Sistema Operacional	Camada de software entre aplicações e hardware
Kernel	Núcleo do SO com acesso total ao hardware (ring 0)
Chamadas de sistema	Única forma de programas acessarem hardware (open, read, write, fork)
Modo usuário vs Modo kernel	Aplicações são restritas; só o kernel toca o hardware
Unix-like	macOS e Linux compartilham os mesmos conceitos e comandos
Sistema init (PID 1)	Primeiro processo; gerencia todos os outros serviços (systemd, launchd)
Filosofia Unix	"Faça uma coisa e faça bem": também é bom design em Rails