Fundamentos de SO e Ambiente Linux

Conceitos-chave

Um Sistema Operacional (SO) é o software que atua como intermediário entre o hardware e os programas do usuário. Ele fornece abstrações (arquivos, processos, sockets) e garante isolamento, segurança e compartilhamento de recursos entre múltiplos programas simultâneos.

Segundo a LPI (Linux Essentials, Topic 4 — The Linux Operating System), o termo "Linux" refere-se tecnicamente apenas ao kernel. O que instalamos e usamos no dia a dia é uma distribuição: o kernel Linux somado a milhares de programas do projeto GNU, bibliotecas, um sistema de init, um gerenciador de pacotes e utilitários. Por isso a Free Software Foundation defende o nome GNU/Linux para o sistema completo.

As duas grandes responsabilidades do kernel

Todo SO existe para resolver dois problemas fundamentais que aparecem quando vários programas disputam um mesmo computador:

• Abstração — transformar hardware complicado e heterogêneo em interfaces simples e uniformes. O programa lê um "arquivo" sem saber se ele está num SSD NVMe, num HD SATA ou num pen-drive USB; abre um "socket" sem conhecer o driver da placa de rede.
• Arbitragem — decidir quem usa a CPU, a memória e os dispositivos, quando e por quanto tempo, impedindo que um programa interfira nos outros (isolamento) ou monopolize os recursos (escalonamento justo).

Abstrações fundamentais oferecidas pelo SO

O princípio "tudo é um arquivo"

Uma das ideias centrais herdadas do Unix é que a maioria dos recursos é exposta como arquivos, manipuláveis com as mesmas syscalls (open, read, write, close). Isso dá uma coerência enorme ao sistema:

# Um terminal é um arquivo — escrever nele mostra texto na tela de outro TTY
$ tty
/dev/pts/0
$ echo "olá" > /dev/pts/0     # aparece no próprio terminal

# Um disco é um arquivo de bloco
$ ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 Jul 20 10:00 /dev/sda

# /dev/null descarta tudo; /dev/zero produz zeros infinitos
$ echo "isto some" > /dev/null
$ head -c 8 /dev/zero | xxd
00000000: 0000 0000 0000 0000                      ........

Multitarefa e multiusuário

Diferente de sistemas antigos, o Linux é multitarefa preemptiva (o kernel pode interromper um processo a qualquer momento para dar a vez a outro) e multiusuário (vários usuários com identidades e permissões distintas podem trabalhar simultaneamente). O escalonador (scheduler) cria a ilusão de que tudo roda ao mesmo tempo, alternando processos na CPU em fatias de milissegundos.

Monolítico vs. microkernel

O Linux é um kernel monolítico modular: drivers, sistema de arquivos e pilha de rede rodam todos em kernel space (desempenho alto), mas podem ser carregados e descarregados em tempo real como módulos. Isso o diferencia de microkernels (como o Minix), que mantêm o mínimo em kernel space e empurram serviços para user space (maior isolamento, menor desempenho).

$ lsmod | head -5           # módulos carregados
Module                  Size  Used by
ext4                  980992  1
xhci_pci               24576  0
snd_hda_intel         57344  3

$ modinfo ext4 | head -3    # metadados de um módulo
# modprobe -r módulo        # descarrega (necessita root)

Linha do tempo do Linux

# Marcos históricos relevantes
1969  → Unix (Bell Labs — Thompson, Ritchie)
1983  → Projeto GNU (Richard Stallman)
1991  → Linux Kernel 0.01 (Linus Torvalds)
1992  → GPL + GNU + Linux = GNU/Linux
1993  → Slackware (1ª distro popular)
1994  → Red Hat Linux
2004  → Ubuntu (Canonical)
Hoje  → +600 distribuições ativas

Arquitetura em camadas

Modos de operação da CPU

A separação entre kernel e aplicações não é apenas uma convenção de software: ela é imposta pelo hardware. A CPU possui pelo menos dois níveis de privilégio (rings ou protection rings):

• Ring 0 (Kernel Mode / modo supervisor) — acesso irrestrito a hardware, a todas as instruções da CPU e a toda a memória física; código do kernel roda aqui.
• Ring 3 (User Mode) — acesso restrito; instruções privilegiadas (acessar diretamente disco, configurar a MMU, mascarar interrupções) são proibidas. Todo código de aplicação roda aqui.

Se um programa em Ring 3 tenta executar uma instrução privilegiada ou acessar memória que não é sua, a CPU dispara uma exceção (fault) e o kernel assume o controle — tipicamente enviando o sinal SIGSEGV (o clássico "Segmentation fault"). É esse mecanismo que garante o isolamento: um bug ou um programa malicioso não consegue derrubar o sistema inteiro nem espionar a memória de outro processo.

Por que precisamos de syscalls?

Como o código de usuário não pode tocar o hardware diretamente, ele precisa pedir ao kernel que faça a operação em seu nome. Esse pedido é a chamada de sistema (system call) — a única porta de entrada controlada do user space para o kernel space. Abrir um arquivo, criar um processo, enviar um pacote de rede, alocar memória: tudo passa por uma syscall.

Na prática, o programador raramente invoca a syscall "crua". A glibc (biblioteca C padrão do GNU) oferece funções wrapper com o mesmo nome (open(), read(), fork()…) que preparam os argumentos, disparam a instrução syscall e traduzem erros para a variável global errno. A LPI (LPIC-1 101.1) trata justamente dessa fronteira entre aplicação, biblioteca e kernel.

Ciclo de uma Syscall

A syscall vista do código C

O exemplo abaixo abre um arquivo e lê seus primeiros bytes usando apenas syscalls (via wrappers da glibc) — sem fopen/printf de alto nível. Note o padrão universal do Unix: retorno < 0 indica erro, e o motivo fica em errno.

#include <fcntl.h>      // open, O_RDONLY
#include <unistd.h>     // read, write, close
#include <stdio.h>      // perror

int main(void) {
    int fd = open("/etc/hostname", O_RDONLY);   // syscall open()
    if (fd < 0) { perror("open"); return 1; }    // erro -> errno

    char buf[128];
    ssize_t n = read(fd, buf, sizeof buf);       // syscall read()
    if (n < 0) { perror("read"); return 1; }

    write(1, buf, n);   // syscall write() no fd 1 = stdout
    close(fd);          // syscall close()
    return 0;
}

$ gcc -Wall le_arquivo.c -o le_arquivo
$ ./le_arquivo
ubuntu-lab

# strace mostra EXATAMENTE as syscalls que o programa fez
$ strace -e trace=open,openat,read,write,close ./le_arquivo
openat(AT_FDCWD, "/etc/hostname", O_RDONLY) = 3
read(3, "ubuntu-lab\n", 128)                = 11
write(1, "ubuntu-lab\n", 11)               = 11
close(3)                                    = 0

Categorias de syscalls (Linux tem ~350)

$ man 2 read        # documentação da syscall read()
$ man 2 syscalls    # lista todas as syscalls do Linux
$ man 2 open        # flags: O_RDONLY, O_CREAT, O_APPEND…

$ strace -e trace=openat ls /etc 2>&1 | head -20
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3

$ uname -r
6.8.0-51-generic

$ uname -a
Linux hostname 6.8.0-51-generic #52-Ubuntu SMP Wed Jan 15 2025 x86_64 GNU/Linux

$ cat /proc/version
Linux version 6.8.0-51-generic (buildd@...) (gcc version 13.3.0)

O que é o Shell?

O shell é um interpretador de comandos — um programa em user space que lê linhas de texto, interpreta-as e instrui o kernel (via syscalls) a executar as ações desejadas. O Bash (Bourne Again SHell) é o shell padrão na grande maioria das distribuições Linux.

Shells mais comuns

Anatomia de um comando

# comando  [opções]  [argumentos]
ls      -lah      /var/log

# ls   → nome do programa (executável em /bin/ls)
# -lah → flags: long format, all files, human-readable sizes
# /var/log → argumento: diretório alvo

Quando você tecla Enter, o Bash faz muito mais do que "rodar o programa". Ele percorre um pipeline de etapas: expansões (curinga, variáveis, aritmética), tokenização, resolve se a palavra é um builtin, alias, função ou executável no PATH, e então usa as syscalls fork() + execve() para criar o processo. Entender essas etapas é o que separa "decorar comandos" de realmente dominar a linha de comando (LPI, Linux Essentials Topic 3; LPIC-1 103.1).

Builtin, alias ou executável?

Nem todo comando é um arquivo no disco. Alguns são builtins — implementados dentro do próprio Bash (como cd, que precisa ser builtin para mudar o diretório do próprio shell). Use type para descobrir a natureza de qualquer comando:

$ type cd echo ls ll
cd is a shell builtin
echo is a shell builtin
ls is aliased to `ls --color=auto'
ll is aliased to `ls -alF'

$ type -a echo     # mostra TODAS as formas de echo (builtin + /usr/bin/echo)
echo is a shell builtin
echo is /usr/bin/echo

Variáveis: do shell e de ambiente

Uma variável de shell existe só na sessão atual. Ao usar export, ela vira uma variável de ambiente, herdada por todos os processos-filho. Não use espaços ao redor do =.

$ nome="Marco"          # variável de shell (local)
$ echo "Olá, $nome"
Olá, Marco

$ export EDITOR=vim     # vira variável de ambiente
$ env | grep EDITOR     # aparece no ambiente
EDITOR=vim

# Variáveis de ambiente importantes
$ echo $HOME $USER $SHELL $PATH
/home/marco marco /usr/bin/bash /usr/local/bin:/usr/bin:/bin

Expansões do shell

Antes de executar, o Bash reescreve a linha de comando. As expansões mais usadas:

# Curinga (globbing): * ? [ ]
$ ls *.txt              # todos que terminam em .txt
$ ls arquivo?.log       # ? = exatamente 1 caractere
$ ls foto[1-3].png      # foto1, foto2 ou foto3

# Expansão de chaves (brace) — gera sequências
$ echo arq_{a,b,c}.txt
arq_a.txt arq_b.txt arq_c.txt
$ mkdir -p projeto/{src,bin,docs}   # cria 3 subpastas de uma vez

# Til (~) = home; e substituição de comando $( )
$ echo ~                /home/marco
$ echo "Hoje é $(date +%A)"
Hoje é Monday

# Expansão aritmética $(( ))
$ echo $((2 + 3 * 4))   14

Quoting: aspas simples × duplas × escape

Controlar quando o shell expande é essencial. Aspas duplas preservam espaços mas ainda expandem $variáveis; aspas simples preservam tudo literalmente.

$ preco=50
$ echo "Custa $preco reais"     Custa 50 reais
$ echo 'Custa $preco reais'     Custa $preco reais
$ echo "Aspas: \" e cifrão: \$"  Aspas: " e cifrão: $

Comandos essenciais — prática imediata

$ whoami            # nome do usuário atual
marcos

$ id               # UID, GID e grupos
uid=1000(marcos) gid=1000(marcos) groups=1000(marcos),27(sudo)

$ pwd              # diretório atual
/home/marcos

$ hostname         # nome da máquina
ubuntu-lab

$ cd /             # vai para a raiz
$ ls               # lista o conteúdo
bin  boot  dev  etc  home  lib  media  mnt  opt  proc  root  run  srv  sys  tmp  usr  var

$ cd ~             # vai para o home do usuário
$ ls -lah          # lista com detalhes

$ man ls           # manual completo
$ ls --help        # ajuda rápida
$ type ls          # é builtin, alias ou executável?
ls is /usr/bin/ls

$ which bash       # localiza o executável
/usr/bin/bash

Redirecionamentos e pipes — o coração do Unix

A filosofia Unix diz: "faça programas pequenos que façam uma coisa bem, e que trabalhem juntos". Isso só é possível porque cada processo tem três canais padrão — os descritores 0 (stdin), 1 (stdout) e 2 (stderr) vistos no Bloco 2 — e o shell permite redirecioná-los para arquivos ou conectá-los entre processos com pipes.

# >  redireciona stdout para arquivo (SOBRESCREVE)
$ ls /etc > lista.txt

# >> ANEXA ao final do arquivo (não apaga)
$ date >> lista.txt

# <  lê stdin de um arquivo
$ wc -l < lista.txt
142

# 2>  redireciona apenas stderr (erros)
$ ls /naoexiste 2> erros.txt
# 2>/dev/null → descarta mensagens de erro
$ find / -name "*.conf" 2>/dev/null | head

# &>  redireciona stdout E stderr juntos para o mesmo lugar
$ comando &> saida_completa.log

# Encadeie filtros para construir consultas poderosas
$ cat /etc/passwd | grep "/bin/bash" | wc -l
3   # quantos usuários têm o bash como shell de login

# Os 5 comandos mais usados no seu histórico
$ history | awk '{print $2}' | sort | uniq -c | sort -rn | head -5
   87 git
   64 ls
   41 cd
   30 vim
   22 cat

O que é (e o que não é) uma distribuição

Como visto no Bloco 1, o kernel Linux sozinho não faz nada de útil para o usuário final. Uma distribuição (distro) é a montagem de um sistema completo e instalável: kernel + utilitários GNU + bibliotecas + sistema de init + gerenciador de pacotes + instalador + política de atualizações. A LPI (Linux Essentials Topic 1) destaca que a principal diferença prática entre distros para o administrador está em três eixos:

• Gerenciador de pacotes e formato (.deb via apt/dpkg × .rpm via dnf/rpm).
• Modelo de lançamento: fixed release (versões estáveis periódicas, ex.: Debian, Ubuntu LTS) × rolling release (atualização contínua, ex.: Arch).
• Filosofia e público: estabilidade corporativa (RHEL), facilidade (Ubuntu), minimalismo/containers (Alpine), controle total (Arch).

Principais famílias de distribuições

Gerenciadores de pacotes — comandos equivalentes

Saber "traduzir" a mesma operação entre famílias é uma habilidade cobrada na LPIC-1 (Objectives 102.4 e 102.5). Todos resolvem o mesmo problema — instalar software e suas dependências — com sintaxes diferentes:

# O arquivo padronizado /etc/os-release funciona em QUALQUER distro moderna
$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
ID=ubuntu
ID_LIKE=debian

$ lsb_release -a 2>/dev/null   # alternativa (nem sempre instalada)

Hierarquia do Sistema de Arquivos (FHS)

O Filesystem Hierarchy Standard é uma especificação que define onde cada tipo de arquivo deve ficar, garantindo que um administrador saiba encontrar as coisas em qualquer distribuição. Duas ideias organizam a hierarquia (LPIC-1 104.7):

• Estático × variável: /usr e /bin quase não mudam (podem ser read-only); /var e /tmp mudam o tempo todo.
• Compartilhável × local: /usr pode ser compartilhado por rede entre máquinas; /etc e /boot são específicos de cada host.

Caminho absoluto × relativo

Um caminho absoluto começa em / (a raiz) e é sempre o mesmo, independente de onde você esteja. Um caminho relativo parte do diretório atual. . é o diretório atual, .. é o pai e ~ é o home.

$ cd /var/log
$ cat syslog          # relativo → /var/log/syslog
$ cat /etc/hostname   # absoluto → sempre o mesmo
$ cd ../..            # sobe dois níveis → /
$ cd -                # volta ao diretório anterior

$ ls -ld /bin /sbin /lib   # veja os symlinks do /usr merge
$ ls -lah /
$ du -sh /var/log/*  2>/dev/null | sort -rh | head -10
$ file /dev/null /dev/zero /dev/random
/dev/null:   character special (1/3)
/dev/zero:   character special (1/5)
/dev/random: character special (1/8)

O que é, afinal, um processo?

No Bloco 1 vimos o processo como uma das grandes abstrações do SO. Agora vamos abrir a caixa. Um processo é um programa em execução: não é o arquivo no disco (isso é o programa), mas a instância viva dele — código carregado na memória, mais todo o estado que o kernel mantém para acompanhá-lo. O mesmo programa (/usr/bin/vim) pode originar dezenas de processos simultâneos e independentes.

A imagem de um processo na memória

Cada processo enxerga seu próprio espaço de endereços virtual (Bloco 2), organizado em regiões bem definidas:

Além da memória, o kernel guarda para cada processo um bloco de controle (o PCB, no Linux a estrutura task_struct) com sua identidade e contexto:

Como um processo nasce: fork() + execve()

No Unix, um processo não é criado do nada — ele é sempre clonado de um pai. O par de syscalls fork() + execve() é o coração do modelo:

Estados de um processo

O kernel move cada processo entre estados conforme ele disputa a CPU ou espera por I/O. A coluna STAT de ps aux mostra a letra do estado:

Um zumbi (Z) é normal e efêmero — some assim que o pai faz wait(). Vira problema só quando o pai esquece de coletar e acumula zumbis. Um órfão (pai morreu antes do filho) é adotado pelo PID 1, que faz o wait() por ele.

Como o kernel decide quem roda: o escalonador

Há sempre mais processos prontos (R) do que núcleos de CPU. O escalonador (scheduler, no Linux o CFS — Completely Fair Scheduler) reparte a CPU em fatias de tempo de milissegundos e alterna os processos tão rápido que criam a ilusão de simultaneidade (multitarefa preemptiva, Bloco 1). Trocar de processo exige um context switch: salvar os registradores do atual e carregar os do próximo — barato, mas não gratuito.

A prioridade influencia quanto tempo cada um recebe. O valor nice vai de -20 (mais prioritário) a +19 (mais "gentil", cede a CPU). Usuários comuns só conseguem aumentar o nice (baixar a prioridade); baixá-lo exige root.

$ ps -o pid,ppid,stat,ni,comm -p $$   # dados do próprio shell ($$ = PID atual)
    PID    PPID STAT  NI COMMAND
   2841    2833 Ss     0 bash

# Iniciar um processo com prioridade reduzida
$ nice -n 10 sleep 100 &
$ renice -n 15 -p 4567   # mudar a prioridade de um processo já rodando

# O kernel expõe TUDO sobre um processo em /proc/PID
$ cat /proc/$$/status | grep -E "State|Pid|PPid|Uid"
State:  S (sleeping)
Pid:    2841
PPid:   2833
Uid:    1000    1000    1000    1000

$ ls /proc/$$/fd     # descritores de arquivo abertos pelo shell
0  1  2  255

Sinais: conversando com processos

O kernel entrega sinais — interrupções assíncronas — para pedir que um processo pare, recarregue ou termine. Você os dispara com Ctrl+C, Ctrl+Z ou o comando kill (que, apesar do nome, apenas envia um sinal):

Por que aprender a ler o man vale mais que decorar comandos

Ninguém memoriza todas as flags de todos os comandos — nem precisa. Um administrador proficiente sabe encontrar a resposta na documentação que já vem instalada na própria máquina, offline. A porta de entrada é o man (manual): cada comando, syscall, arquivo de configuração e função de biblioteca tem sua página. Saber navegá-las é objetivo explícito da LPI (LPIC-1 103.1).

As seções do manual

O manual é dividido em seções numeradas. Isso importa porque o mesmo nome pode existir em várias — por exemplo, existe o comando printf (seção 1) e a função C printf (seção 3):

Anatomia de uma página de manual

Toda página segue a mesma estrutura padronizada — aprenda a "saltar" direto para a parte que interessa:

Navegando dentro do man

O man usa o paginador less. As teclas essenciais para não ficar perdido:

Quando você não sabe o nome do comando

O maior valor do sistema de manuais aparece quando você sabe o que quer fazer, mas não qual comando usar. É aí que entram a busca por palavra-chave e o resumo:

# Buscar por palavra-chave em TODAS as descrições (NAME) das páginas
$ apropos "copy files"      # idêntico a: man -k "copy files"
cp (1)               - copy files and directories
install (1)          - copy files and set attributes
scp (1)              - secure copy (remote file copy program)

# Resumo de uma linha de um comando (a seção NAME)
$ whatis ls             # idêntico a: man -f ls
ls (1)               - list directory contents

# Em quais seções existe uma página com esse nome?
$ man -f printf
printf (1)           - format and print data
printf (3)           - formatted output conversion

Além do man: outras fontes na máquina

$ ls --help            # ajuda rápida embutida no próprio programa (builtins e GNU)
$ help cd              # ajuda de um BUILTIN do Bash (cd não tem man próprio)
$ info coreutils       # manual hipertexto do GNU, mais extenso que o man
$ ls /usr/share/doc/   # READMEs, changelogs e exemplos dos pacotes instalados