← Voltar ao Encontro 2
SISTEMAS OPERACIONAIS · ADS23 · ENCONTRO 2
Encontro 2 de 17 · Sistemas Operacionais

Hardware e tipos de SO

O que a máquina tem por baixo do capô — e como o próprio sistema operacional te deixa espiar isso, sem abrir o gabinete.

EIXO DO CURSODocker & containers
DE ONDE VIEMOSO que é um SO (Enc. 1)
PARA ONDE VAMOSArquiteturas de SO (Enc. 3)
$ systemctl status hardware.target
Recapitulando

No Encontro 1, o SO usava dois óculos

Vimos que todo sistema operacional faz duas coisas ao mesmo tempo: entrega uma máquina estendida pros programas, e atua como gerenciador de recursos por trás das cortinas.

🖥️ Máquina estendida

Esconde a complexidade do hardware. Você digita cat arquivo.txt e nunca precisa saber em que setor do disco os bytes estão.

🧮 Gerenciador de recursos

Decide quem usa a CPU agora, quanta memória cada processo recebe, e em que ordem o disco atende os pedidos.

Hoje a pergunta muda de direção: o que exatamente é esse hardware que o SO está gerenciando? E como fazemos pra ver essa gestão acontecendo, ao vivo, no terminal?
Por dentro da máquina

O vocabulário mínimo de hardware

Não é curso de arquitetura de computadores — é o suficiente pra você, como profissional de ADS, entender o que pode estar limitando a performance de uma aplicação.

⚙️ CPU

Executa instruções. Tem núcleos (cores) e cache. É o recurso que os processos disputam entre si.

lscpu

🧠 Memória (RAM)

Rápida e volátil — perde tudo ao desligar. Onde os programas em execução vivem enquanto rodam.

free -h

💾 Disco

Lento e persistente. Guarda tudo mesmo desligado. É o gargalo clássico de E/S.

df -h

🔌 E/S e barramento

Teclado, rede, USB — e a "estrada" que liga tudo isso à CPU e à memória.

lsusb / lspci
PROCESSA
CPU
GUARDA (TEMP.)
Memória
GUARDA (PERM.)
Disco
CONVERSA COM FORA
E/S
tudo conectado pelo barramento — a via de mão dupla entre os componentes
O zoológico dos sistemas operacionais

Nem todo SO é feito pra fazer a mesma coisa

Tanenbaum descreve o hardware por trás de cada categoria de SO. O mesmo Linux que você instalou aparece em quase todas elas.

01

Mainframe

Salas inteiras de disco. Lote, transações, tempo compartilhado.

02

Servidor

Atende muitos clientes via rede. Linux, FreeBSD, Windows Server.

03

Multiprocessador

Várias CPUs, um sistema só. Todo notebook multinúcleo entra aqui.

04

Computador pessoal

Foco em um único usuário. É a sua VM Ubuntu agora.

05

Portátil / móvel

Tablets e smartphones. Android é Linux por baixo.

06

Embarcado

Roda dentro de um forno de micro-ondas. Sem instalar apps.

07

Nó sensor

Minúsculo, à bateria, orientado a eventos. TinyOS é exemplo clássico.

08

Tempo real

Prazo é lei. Um robô soldador não pode atrasar a solda.

Por que isso importa pra você? Quando for escolher onde rodar uma aplicação — um container num servidor, um app num celular — o tipo de SO por trás muda completamente o que é possível e o que é prioridade.
A ponte entre teoria e terminal

/proc: o SO te deixa espiar por dentro

O /proc parece uma pasta comum, mas é um sistema de arquivos virtual: nada ali existe fisicamente no disco. É uma janela ao vivo para dentro do núcleo (kernel).

Os dados de /proc/uptime só são gerados no instante em que você lê o arquivo — e mudam a cada leitura. Não é um arquivo, é uma pergunta feita ao kernel disfarçada de arquivo.
$ cat /proc/uptime
3841.92 3714.05
$ cat /proc/uptime
3846.17 3717.83
↑ dois números diferentes — o arquivo "muda sozinho" porque não é um arquivo de verdade.
Do conceito ao comando

Cada pedaço de hardware tem uma janela no /proc

HardwareComando rápidoJanela em /procO que revela
CPUlscpu/proc/cpuinfoModelo, núcleos, cache, velocidade
Memóriafree -h/proc/meminfoRAM total, em uso, livre, swap
Kerneluname -r/proc/versionVersão exata do núcleo Linux
Tempo ativouptime/proc/uptimeHá quanto tempo a máquina está ligada
Discodf -h/proc/mountsEspaço usado e pontos de montagem
Eixo do curso

Um spoiler sobre containers

🐳

Um container não tem hardware próprio

Quando você roda docker run, o container enxerga o mesmo /proc do host — só que com limites. Um docker run --memory=512m não muda a RAM física da máquina: ele restringe o que aquele processo pode enxergar e usar dela.

Voltamos nisso com força no Encontro 4
Mão na massa

Sua vez de abrir o capô

Nos próximos ~90 minutos você vai rodar lscpu, free -h e explorar o /proc na sua própria VM — e escrever três observações conectando o que viu com o que acabamos de discutir.

Roteiro de Laboratório — Encontro 2

Comandos explicados passo a passo, dicas pra quem travar, e o checklist final pro seu portfólio.

Abrir Roteiro-Aluno_Encontro-02.html →
Para ler

Fechando o Encontro 2

A leitura vem depois da aula, como fechamento — e já prepara o Encontro 3. Confira o mapa completo em Mapa_de_Leituras_SO_ADS23.md.

🟢

LAUREANO — Cap. 9

p. 90–94

O Sistema de Arquivo /procfs. O livro explica exatamente o que você acabou de explorar no laboratório.

🔵

TANENBAUM — 1.4

p. 24–27

O zoológico dos sistemas operacionais. Mainframe, servidor, embarcado, tempo real — onde o Linux do lab se encaixa.

⚪

TANENBAUM — 1.3

p. 14–24

Revisão sobre hardware de computadores. Processadores, memória, discos, barramentos — opcional, pra quem quer ir além.