1) O boot como “pipeline”: firmware → bootloader → kernel

A arquitetura do Linux começa antes do kernel. O que muda de máquina para máquina é o primeiro trecho do fluxo, mas o objetivo é o mesmo: carregar código e parâmetros suficientes para o kernel iniciar e montar o sistema.

• Firmware (BIOS/UEFI): inicializa hardware mínimo (timer, memória, controladores básicos) e transfere o controle para o bootloader.
• Bootloader (ex.: GRUB): carrega o kernel e o initramfs (quando usado), e fornece parâmetros de kernel (ex.: root, console, init).
• Kernel: detecta hardware, inicializa subsistemas (memória, drivers, scheduler) e sobe a etapa de montagem até chegar ao root filesystem.

2) Kernel em camadas: subsistemas, syscalls e o “contrato” com o usuário

O kernel não é “um bloco único”; ele é um conjunto de subsistemas organizados em torno do que realmente importa: processos, memória, I/O, rede e segurança. O espaço do usuário enxerga esse poder via interfaces padronizadas.

• Syscalls: são as chamadas que atravessam a fronteira user/kernel. Em termos práticos, é por elas que ferramentas como shells e serviços pedem serviços ao kernel.
• VFS (Virtual File System): abstrai diferentes sistemas de arquivos sob um conjunto consistente de operações. Isso reduz complexidade para apps e utilitários.
• Gerenciador de memória: controla paginação, cache, mapa de páginas e políticas que afetam latência e throughput.
• Scheduler: define como CPU é distribuída entre threads/processos (e impacta comportamento sob carga).

Uma forma sólida de pensar: o kernel “manda” em recursos, enquanto o espaço do usuário “orquestra”: processos, programas, scripts e serviços chamam o kernel quando precisam de algo.

3) Espaço do usuário: processos, namespaces e o ecossistema de serviços

A arquitetura do Linux no mundo real se organiza em processos. O que diferencia um sistema “simples” de um sistema moderno é como esses processos são organizados e isolados.

• Process Model: cada processo possui espaço de endereçamento próprio, e pode criar filhos (fork/exec) para alterar o código em execução.
• Init system (ex.: systemd): descreve dependências, inicia serviços, coleta status e padroniza logging/journaling.
• Namespaces (quando usados): isolamento por visão. Exemplos típicos são isolamento de PID, rede, montagens e usuários.
• Cgroups: controle e contabilização de recursos (CPU, memória, I/O). Em ambientes com múltiplos workloads, cgroups evitam “um processo dominar o host”.

4) I/O, rede e segurança: de onde vem a “performance” e como ela quebra

A maior parte das instabilidades que vejo em ambientes Linux aparece em I/O e rede — porque são áreas fortemente dependentes de hardware, drivers e configurações. Segurança, por sua vez, adiciona controle de acesso e restrições que, se mal alinhadas, viram “falha por política”.

• Disco e armazenamento: cache do page cache, fila de I/O, camadas do filesystem e comportamento do controlador. Swap também entra quando pressão de memória cresce.
• Rede: buffers de socket, stack de rede, offloads e retransmissões.
• Controle de acesso: permissões UNIX, ownership, além de camadas modernas como políticas de segurança por módulos (dependendo da distro).
• Logging: o ponto onde você confirma hipóteses. Sem logs consistentes, você diagnostica “no escuro”.

Minha regra: sempre tente transformar sintomas em métricas e eventos. “Lento”, “travando” e “timeout” viram decisões quando você consegue correlacionar CPU, memória, I/O e rede.