Moprius

Posted on May 15

Entendendo o Linux por dentro: uma viagem pelas camadas que fazem o sistema funcionar

#linux #systems #kernel #shell

Introdução: por que o Linux parece tão complicado (e por que ele não é, quando você sabe olhar)

Quando você abre um navegador no Linux, digita o endereço de um site e aperta Enter, uma quantidade impressionante de engrenagens invisíveis começa a girar. Um processo conversa com outro processo. Esse outro processo pede ajuda a uma biblioteca compartilhada. Essa biblioteca, por sua vez, faz uma chamada ao núcleo do sistema operacional, que finalmente pede ao hardware que envie sinais elétricos por uma placa de rede. Tudo isso acontece em frações de segundo, sem que você precise pensar em nada disso.

Para quem está começando, esse cenário parece intimidador. Existem dezenas de componentes rodando ao mesmo tempo, trocando mensagens entre si o tempo todo. E a pergunta que fica é: como compreender esse emaranhado sem se perder?

A boa notícia é que existe um método. E ele tem nome: abstração. É justamente com esse conceito que precisamos começar — e é a partir dele que conseguimos enxergar o sistema operacional não como um amontoado confuso, mas como um conjunto bem organizado de camadas com responsabilidades específicas.

Esta postagem é um passeio pelos fundamentos do funcionamento do Linux, indo desde a ideia de níveis e camadas de abstração até os conceitos de usuário e permissões. A ideia é traduzir esses conceitos para uma linguagem clara, com exemplos do dia a dia, para que mesmo quem nunca abriu um terminal consiga sair daqui com uma noção sólida de como o Linux funciona por baixo do capô.

1. Abstração: o segredo para entender qualquer sistema complexo

Antes de mergulhar em qualquer detalhe técnico, precisamos parar e entender o que é abstração. Uma analogia simples com um carro ajuda muito a fixar a ideia.

Imagine que você é apenas um passageiro em um carro. O que você precisa saber para usufruir dessa viagem? Praticamente nada além de como abrir a porta, como afivelar o cinto e talvez como ajustar o banco. Não importa para você quais são os parafusos que prendem o motor, que tipo de óleo lubrifica os pistões, ou como foi pavimentada a estrada. Você está em um nível alto de abstração: usa o produto final sem se preocupar com o que está por baixo.

Agora suponha que você precise dirigir o carro. Subitamente, seu nível de abstração precisa diminuir um pouco. Você ainda não precisa saber montar um motor, mas precisa entender pelo menos três coisas: o próprio carro (tamanho, capacidade, particularidades), os controles (volante, acelerador, embreagem, freio) e as características da estrada (curvas, faixas, sinais de trânsito).

E quando a viagem fica desconfortável, com vibrações estranhas? A abstração ajuda você a diagnosticar o problema de forma estruturada. Pode ser problema no carro? No seu modo de dirigir? Na estrada? Eliminando uma hipótese por vez, você chega à raiz do problema. Se a estrada está esburacada, talvez você queira ir ainda mais fundo: por que a estrada está assim? Houve falta de manutenção? Os operários fizeram um trabalho mal feito?

Esse é exatamente o jeito como engenheiros e desenvolvedores de software pensam quando constroem sistemas operacionais. Em vez de tentar entender tudo de uma vez, eles dividem o sistema em pedaços menores e mais gerenciáveis. Cada pedaço é chamado de subsistema, módulo, pacote ou, de modo mais genérico, componente.

A grande sacada da abstração é que, ao desenvolver um componente, o programador não precisa saber em detalhe como os outros componentes funcionam por dentro — basta saber o que cada um faz e como pedir os serviços que ele oferece. É como ligar para o serviço de entrega: você não precisa saber qual rota o entregador vai fazer ou como ele monta o veículo. Você só precisa saber o número do telefone e o que pedir.

Essa lógica vai guiar todo o resto deste texto. Cada peça do Linux será apresentada não pelos detalhes internos, mas pelo papel que desempenha no funcionamento geral do sistema.

2. Os níveis e camadas de abstração no Linux

A abstração ajuda a dividir o sistema em pedaços, mas, por si só, ela não basta. Precisamos de organização. Os pedaços precisam ser arrumados em camadas, e cada camada se diferencia das outras pela sua proximidade com o hardware ou com o usuário.

No topo dessa pilha, estão as coisas com as quais você interage diretamente: o navegador, o jogo, o editor de texto, o reprodutor de música. Na base, no nível mais fundamental, está o hardware puro — a memória física, os bits, os zeros e uns que circulam pelos circuitos. No meio dessa enorme distância entre o usuário e o hardware, fica o sistema operacional, ocupando várias camadas intermediárias.

No Linux, podemos resumir essa organização em três grandes níveis:

Hardware — a base de tudo. Inclui a memória principal (RAM), uma ou mais unidades centrais de processamento (CPUs), discos, interfaces de rede e quaisquer outros dispositivos físicos.
Kernel — o núcleo do sistema operacional. É um software que reside na memória e atua como intermediário entre o hardware e tudo o que roda acima dele. Ele controla o acesso à memória, decide qual processo usa a CPU, conversa com os dispositivos e fornece serviços essenciais para os programas.
Processos do usuário (espaço do usuário) — todos os programas em execução que o kernel gerencia. Isso inclui a interface gráfica, os servidores, o shell (terminal), os navegadores, enfim, tudo o que executa "por cima" do kernel.

Vale notar que mesmo o termo "processo do usuário" é uma generalização. Quando falamos em "processo do usuário", não estamos nos referindo apenas a programas com os quais um ser humano interage diretamente. Um servidor web, por exemplo, é um processo do usuário, mesmo que nenhum ser humano esteja olhando para a tela enquanto ele atende requisições.

A diferença crítica entre modo kernel e modo usuário

Aqui chegamos a um dos pontos mais importantes do assunto, e que precisa ficar bem claro: o kernel e os processos do usuário rodam em modos diferentes da CPU.

O modo kernel dá acesso irrestrito ao processador e à memória principal. É um poder enorme, mas também perigoso: um erro em código rodando em modo kernel pode corromper ou derrubar o sistema inteiro. A região da memória que só o kernel pode acessar é chamada de kernel space (espaço do kernel).
O modo usuário, por outro lado, restringe o acesso a um subconjunto bem menor da memória e a operações seguras da CPU. A área da memória onde os processos do usuário rodam é chamada de user space (espaço do usuário). Se um processo do usuário falhar — por exemplo, se o navegador travar —, o estrago fica contido: o kernel limpa a bagunça e o resto do sistema continua funcionando.

Esse isolamento é o que permite que seu navegador trave sem que o cálculo científico que está rodando em segundo plano há três dias seja perdido. Cada processo está numa caixinha protegida, e essa caixinha só pode ser aberta pelo kernel.

Em teoria, um processo do usuário não consegue causar danos sérios ao sistema. Na prática, depende: se ele tiver as permissões certas, pode sim, por exemplo, apagar dados de um disco. Existem salvaguardas para evitar esse tipo de problema, mas o ponto é que o conceito de "modo" cria uma barreira clara entre o que é seguro e o que é privilegiado.

Há também uma curiosidade: o kernel do Linux pode rodar threads de kernel, que se parecem com processos comuns, mas têm acesso ao espaço do kernel. Exemplos são kthreadd e kblockd. Se um dia você ver esses nomes na lista de processos, saiba que eles não são programas do usuário — são parte do próprio kernel.

3. Hardware: a importância da memória principal

De todo o hardware presente em um computador, talvez nenhum seja tão fundamental quanto a memória principal (a famosa RAM). Em sua forma mais bruta, ela não passa de uma enorme área de armazenamento cheia de zeros e uns. Cada espacinho que guarda um zero ou um um é chamado de bit.

Pode parecer pouco glamoroso, mas é nessa memória que tudo acontece: tanto o kernel em execução quanto os processos do usuário estão ali, na forma de gigantescas coleções de bits. Toda a entrada e saída de dispositivos periféricos (teclado, mouse, disco, rede) também passa pela memória, em forma de bits. A CPU, por sua vez, é essencialmente um operador da memória: ela lê instruções e dados da memória, processa, e escreve resultados de volta na memória.

Esse é um ponto que muita gente nunca para para pensar: a CPU "não conhece" os programas como nós os conhecemos. Para ela, tudo o que existe são padrões de bits a serem lidos e manipulados na memória.

O conceito de estado

Quando falamos sobre memória, processos ou kernel, um termo aparece com frequência: estado. Tecnicamente, um estado é uma configuração específica de bits em um determinado momento. Por exemplo, se você tem quatro bits, as combinações 0110, 0001 e 1011 representam três estados diferentes.

Acontece que um único processo pode envolver milhões de bits. Falar em estado em termos de bits, então, fica impraticável. Por isso usamos descrições abstratas: em vez de listar bits, dizemos coisas como "o processo está esperando entrada do usuário" ou "o processo está na etapa 2 da inicialização".

E há ainda outro termo que merece atenção: imagem. Como geralmente nos referimos ao estado de forma abstrata, quando queremos falar do arranjo físico dos bits propriamente dito, usamos a palavra "imagem". Você ouvirá isso em contextos como "imagem de processo" ou "imagem do sistema".

4. O Kernel: o cérebro silencioso do sistema

Se a memória é o palco onde tudo acontece, o kernel é o diretor que organiza a peça. Praticamente tudo o que o kernel faz gira em torno da memória principal: ele a divide em pedaços, distribui esses pedaços entre os processos, mantém registros sobre quem está com o quê, e garante que ninguém invada o espaço alheio.

O kernel é responsável por quatro grandes áreas:

Processos — decide qual processo pode usar a CPU em cada momento.
Memória — controla a memória, sabendo o que está alocado para quem, o que pode ser compartilhado e o que está livre.
Drivers de dispositivos — atua como interface entre os processos e o hardware (disco, placa de rede, etc.).
Chamadas de sistema e suporte — fornece os mecanismos pelos quais os processos se comunicam com o kernel para pedir serviços.

Vamos explorar cada uma dessas áreas.

4.1 Gerenciamento de processos

Gerenciar processos significa iniciá-los, pausá-los, retomá-los, agendá-los e finalizá-los. Iniciar e terminar processos é relativamente simples de entender. O que é mais sutil é como um processo realmente usa a CPU durante seu funcionamento.

Em um sistema operacional moderno, é comum que muitos processos rodem "simultaneamente". Por exemplo, você pode ter um navegador, uma planilha, um editor de texto e um tocador de música todos abertos ao mesmo tempo. Mas há uma armadilha aqui: eles não rodam exatamente ao mesmo tempo, pelo menos não em uma CPU com apenas um núcleo.

Em um sistema com CPU de um único núcleo, vários processos podem estar prontos para usar a CPU, mas apenas um efetivamente usa o processador a cada instante. Na prática, cada processo usa a CPU por uma fração mínima de segundo, depois é pausado; outro processo então usa a CPU por outra fração; e assim por diante. Esse "trocar de turno" entre processos chama-se context switch (troca de contexto).

Cada pedaço de tempo que um processo recebe é chamado de time slice (fatia de tempo). É um intervalo curto o suficiente para que humanos não percebam a alternância, mas longo o suficiente para que computações significativas possam ser feitas. Essa habilidade de fazer parecer que vários processos rodam ao mesmo tempo recebe o nome de multitarefa (multitasking).

Quem gerencia tudo isso é o kernel. Imagine que um processo está rodando em modo usuário e sua fatia de tempo se esgota. O que acontece, passo a passo, é o seguinte:

A CPU (o hardware em si) interrompe o processo atual com base em um temporizador interno, muda para o modo kernel e devolve o controle ao kernel.
O kernel registra o estado atual da CPU e da memória — informações essenciais para retomar o processo interrompido mais tarde.
O kernel executa quaisquer tarefas que tenham surgido durante a fatia de tempo anterior (por exemplo, coletar dados de operações de entrada e saída, ou I/O).
O kernel está agora pronto para deixar outro processo rodar. Ele examina a lista de processos prontos para executar e escolhe um.
O kernel prepara a memória para esse novo processo e configura a CPU.
O kernel diz à CPU quanto tempo será a fatia desse novo processo.
O kernel coloca a CPU de volta no modo usuário e entrega o controle ao processo escolhido.

Essa sequência responde a uma pergunta importante: quando o kernel realmente roda? A resposta é: ele roda entre as fatias de tempo dos processos, durante essas trocas de contexto.

No caso de máquinas com múltiplos núcleos — quase todas hoje em dia —, a situação fica um pouco mais complexa, porque o kernel não precisa abrir mão do seu CPU atual para que um processo rode em outro núcleo. Mais de um processo pode efetivamente rodar ao mesmo tempo. Ainda assim, para aproveitar ao máximo os núcleos disponíveis, o kernel costuma executar as mesmas etapas descritas acima.

4.2 Gerenciamento de memória

Durante uma troca de contexto, o kernel também precisa gerenciar a memória, e essa tarefa pode ser bem complicada. Algumas condições precisam ser garantidas o tempo todo:

O kernel precisa ter sua própria área privada na memória, inacessível aos processos do usuário.
Cada processo do usuário precisa ter sua própria seção de memória.
Um processo do usuário não pode acessar a memória privada de outro processo.
Processos do usuário podem compartilhar memória entre si, quando isso for explicitamente necessário.
Parte da memória de um processo pode ser somente leitura.
O sistema pode usar mais memória do que existe fisicamente, recorrendo ao espaço em disco como auxiliar.

Felizmente, o kernel não faz isso sozinho. As CPUs modernas incluem um componente chamado MMU (Memory Management Unit), ou Unidade de Gerenciamento de Memória. É a MMU que viabiliza um esquema chamado memória virtual.

Na memória virtual, um processo não acessa a memória diretamente pelo endereço físico no hardware. Em vez disso, o kernel configura cada processo como se ele estivesse rodando sozinho em uma máquina inteira. Quando o processo tenta acessar um endereço de memória, a MMU intercepta esse acesso e usa um mapa de endereços para traduzir aquele "endereço do ponto de vista do processo" para o endereço físico real na máquina.

O kernel é quem mantém esse mapa atualizado. Durante uma troca de contexto, por exemplo, ele precisa trocar o mapa do processo que estava rodando pelo mapa do processo que vai rodar agora. A implementação concreta desse mapa de endereços é chamada de tabela de páginas (page table).

Esse esquema dá a cada processo a ilusão de ter uma máquina inteira só para si, com seu espaço próprio de memória, sem que ele precise se preocupar com o que os outros processos estão fazendo. É uma das abstrações mais poderosas que existem em sistemas operacionais.

4.3 Drivers de dispositivos e o gerenciamento de hardware

O papel do kernel em relação aos dispositivos é, em essência, simples: ele é o porteiro. Um dispositivo geralmente só pode ser acessado em modo kernel, porque um acesso inadequado — como um processo pedindo para desligar a fonte de energia — poderia derrubar a máquina.

A complicação real está em outro lugar: dispositivos diferentes raramente compartilham a mesma interface de programação, mesmo quando fazem essencialmente a mesma coisa. Duas placas de rede de fabricantes diferentes, por exemplo, podem ser totalmente distintas por dentro, com comandos próprios, registradores próprios e quirks próprios.

Por causa disso, os drivers de dispositivos tradicionalmente fazem parte do kernel. O papel deles é tornar a vida dos desenvolvedores de software mais fácil: eles "traduzem" as particularidades de cada hardware e expõem uma interface uniforme para os processos do usuário. Assim, o programador que escreve um software para ler um arquivo não precisa saber se o disco é SSD ou HDD, nem qual é o fabricante. Ele só precisa pedir ao kernel: "leia este arquivo". O kernel, via driver, faz o resto.

4.4 Chamadas de sistema e suporte aos processos

Existem várias outras funcionalidades que o kernel oferece aos processos do usuário. A mais essencial delas são as chamadas de sistema (em inglês, system calls, ou simplesmente syscalls).

Uma chamada de sistema é um mecanismo pelo qual um processo do usuário pede ao kernel que execute alguma tarefa que o próprio processo não conseguiria fazer sozinho, ou não conseguiria fazer com segurança. Abrir arquivos, ler arquivos, escrever em arquivos — tudo isso envolve chamadas de sistema. Sem elas, processos seriam ilhas isoladas, incapazes de interagir com qualquer coisa fora de si mesmos.

Duas chamadas de sistema são particularmente importantes para entender como os processos começam a existir:

fork() — quando um processo chama fork(), o kernel cria uma cópia quase idêntica desse processo. Há agora dois processos rodando, ambos com o mesmo código, a mesma memória, o mesmo estado.
exec() — quando um processo chama exec(programa), o kernel carrega e inicia o programa especificado, substituindo o processo atual. O processo antigo deixa de existir, e em seu lugar surge o novo programa, mas com o mesmo identificador.

Com exceção do init (o primeiríssimo processo, que é iniciado pelo kernel durante o boot), todos os processos do usuário em um sistema Linux começam por meio de fork(). E, na maioria das vezes, esse novo processo recém-clonado imediatamente chama exec() para virar outro programa.

Um exemplo simples ajuda a entender essa dança. Quando você digita ls em um terminal e aperta Enter, o seguinte acontece:

O shell (o programa do terminal) chama fork() para criar uma cópia de si mesmo.
Essa cópia, ainda idêntica ao shell original, chama exec(ls) para se transformar no programa ls.
O ls roda, lista os arquivos do diretório atual, e termina.
O shell original, que esperou todo esse tempo, volta a aceitar comandos.

Pode parecer estranho criar uma cópia inteira só para substituí-la em seguida, mas esse padrão fork() + exec() é elegante porque permite ao novo processo herdar todo o ambiente do pai (variáveis, arquivos abertos, permissões) antes de mudar de identidade.

Vale uma nota sobre a notação: chamadas de sistema costumam ser escritas com parênteses, como fork() e exec(), derivando da forma como elas seriam escritas em código C. Você não precisa saber C para entender isso — basta lembrar que uma chamada de sistema é uma interação entre um processo e o kernel.

Além das chamadas de sistema tradicionais, o kernel também oferece pseudodispositivos. Eles aparecem para os processos como se fossem dispositivos comuns, mas, na verdade, são implementados puramente em software. Um exemplo clássico é o gerador de números aleatórios /dev/random. Tecnicamente, ele não precisaria estar no kernel, mas costuma ficar por razões práticas, especialmente de segurança.

5. Espaço do usuário: onde a ação acontece

Como já vimos, a memória principal que o kernel reserva para os processos do usuário é o que chamamos de user space (ou espaço do usuário). Como um processo nada mais é do que um estado na memória, o espaço do usuário acaba sendo, na prática, a memória ocupada por todos os processos rodando ao mesmo tempo. Você também pode encontrar o termo informal userland para se referir à mesma coisa, e às vezes ele é usado para se referir aos próprios programas que rodam ali.

E aqui vai uma constatação importante: a maior parte da ação em um sistema Linux acontece no espaço do usuário. O kernel é fundamental, mas é um trabalhador silencioso, quase invisível. Tudo o que você vê — a interface gráfica, o navegador, o editor de texto, o servidor que serve suas páginas, o banco de dados que guarda seus posts — é processo do usuário.

Embora, do ponto de vista do kernel, todos os processos sejam essencialmente iguais, eles desempenham papéis muito diferentes. Por isso, costuma-se organizar mentalmente o espaço do usuário em camadas de serviço:

Camada inferior (mais próxima do kernel) — componentes pequenos, com tarefas simples e bem definidas. Por exemplo: serviços de configuração de rede, barramento de comunicação entre processos, logging de diagnóstico.
Camada intermediária — componentes maiores, que cuidam de serviços como e-mail, impressão, cache de DNS, banco de dados.
Camada superior — aplicações com as quais o usuário interage diretamente. A interface gráfica, o navegador web, os editores e similares.

Geralmente, quando um componente quer usar outro, esse "outro" está na mesma camada ou em uma camada abaixo. Mas vale dizer que essa hierarquia é uma aproximação. Não existem regras rígidas no espaço do usuário. Servidores web, por exemplo, podem ser considerados aplicações de altíssimo nível (porque suas tarefas são complexas), mas também podem ser vistos como serviços intermediários (porque outras aplicações dependem deles). Tudo depende do ponto de vista.

Outro detalhe que merece atenção: a maioria dos programas escreve mensagens de diagnóstico, conhecidas como logs. O padrão é usar o serviço syslog para isso, mas alguns programas preferem fazer seu próprio logging. É um exemplo claro de como o espaço do usuário é flexível, sem regras absolutas.

6. Usuários: identidades e fronteiras

Até aqui, falamos bastante sobre processos, mas pouco sobre quem é dono deles. É hora de entrar no conceito de usuário.

O kernel do Linux herdou do Unix a noção tradicional de usuário. Um usuário é uma entidade que pode rodar processos e ser dona de arquivos. Um usuário normalmente está associado a um nome — por exemplo, um sistema pode ter um usuário chamado joaoz ou maria. Mas, internamente, o kernel não trabalha com nomes. Ele identifica os usuários por números, chamados IDs de usuário (user IDs, ou UIDs).

Por que existem usuários? Por duas razões principais: permissões e fronteiras. Todo processo do espaço do usuário tem um "dono", e dizemos que aquele processo "roda como" aquele usuário. Esse dono pode encerrar ou modificar o comportamento dos seus próprios processos (dentro de certos limites), mas não pode interferir nos processos de outros usuários. Da mesma forma, usuários podem ser donos de arquivos e decidir se compartilham ou não esses arquivos com outros usuários.

Um sistema Linux normal tem vários usuários além das pessoas reais que efetivamente usam a máquina. Existem usuários de sistema, criados para representar serviços específicos. E há um usuário que merece destaque especial: o root.

O usuário root é a grande exceção das regras de isolamento. Ele pode encerrar e alterar processos de qualquer outro usuário, e pode acessar qualquer arquivo do sistema local. Por isso, ele é conhecido como superusuário. Uma pessoa que pode operar como root é considerada um administrador do sistema na tradição Unix.

Mas atenção: ser root é poderoso e perigoso. O sistema simplesmente confia em tudo o que você manda fazer, mesmo que isso seja claramente destrutivo. Não há rede de proteção. Por isso, os designers de sistemas se esforçam constantemente para tornar o acesso root o menos necessário possível. Trocar de rede sem fio em um notebook, por exemplo, antes exigia ser root, mas hoje em dia é uma operação comum disponível para qualquer usuário comum. Vale ressaltar também que, embora o root seja poderosíssimo, ele ainda roda em modo usuário da CPU, e não em modo kernel.

Existem também os grupos, que são conjuntos de usuários. O propósito principal dos grupos é permitir que um usuário compartilhe arquivos com vários membros ao mesmo tempo, sem precisar abrir o arquivo para todo o sistema.

7. Olhando para frente: o que vem agora?

Chegamos ao final do passeio panorâmico pelos fundamentos do Linux. Vamos recapitular rapidamente o que vimos:

Abstração é a ferramenta mental que permite entender sistemas complexos, ignorando detalhes irrelevantes e focando em propósitos e relações.
O Linux organiza seus componentes em três grandes níveis: hardware na base, kernel no meio, processos do usuário no topo.
O hardware — especialmente a memória principal — é o palco onde tudo se desenrola. CPUs leem e escrevem memória; processos e kernel são, no fundo, padrões de bits.
O kernel é o gerente silencioso: ele cuida de processos (multitarefa, troca de contexto, fatias de tempo), gerencia memória (com a ajuda da MMU e da memória virtual), opera dispositivos (via drivers) e atende às chamadas de sistema dos processos.
O espaço do usuário é onde a ação visível acontece. Os processos do usuário se organizam em camadas — básica, intermediária e de aplicação — mas sem regras rígidas.
Os usuários existem para garantir permissões e fronteiras. O root é o superusuário com poderes especiais.

Essa visão geral é fundamental, mas ela não substitui a prática. Não é possível aprender os detalhes de um sistema Linux apenas lendo sobre ele — é preciso colocar a mão na massa. O próximo passo natural nessa jornada seria começar a explorar os fundamentos do espaço do usuário direto no terminal, e abordar um tema que ficou de fora deste texto: o armazenamento de longo prazo (discos, arquivos, sistemas de arquivos). Afinal, é preciso guardar programas e dados em algum lugar.

Se você está começando a estudar Linux agora, talvez tenha achado tudo isso um pouco abstrato — e é exatamente esse o ponto. A primeira leitura serve para você ter um mapa mental do território. Quando começar a estudar comandos no terminal, processos, memória, redes ou qualquer outro tópico, vai conseguir encaixar cada novo conceito no lugar certo da pilha de abstrações: "ah, isso é uma chamada de sistema", "isso aqui é coisa de driver, então mora no kernel", "isso é só um processo do usuário fazendo o que sabe fazer".

Esse mapa é o que separa quem usa Linux de quem entende o Linux. E entender o Linux é entender, em grande medida, como sistemas operacionais modernos funcionam em geral — porque os mesmos conceitos de modos de execução, processos, memória virtual e chamadas de sistema aparecem, com pequenas variações, no Windows, no macOS, no FreeBSD, no Android e em praticamente qualquer outro sistema operacional sério que exista hoje.

Então, da próxima vez que você abrir o terminal e digitar um comando, lembre: por trás dessa simples linha de texto, um shell vai fazer um fork(), criar uma cópia de si mesmo, transformar essa cópia em outro programa via exec(), conversar com o kernel via chamadas de sistema, escrever em pseudodispositivos como /dev/tty, esperar troca de contexto, lidar com memória virtual mapeada pela MMU, e voltar a você com o resultado. Tudo isso em milissegundos. E agora você sabe o nome de quase todas as engrenagens envolvidas.

Bem-vindo ao Linux. A viagem está só começando.

DEV Community