Esse post no x me deixou com vontade de escrever sobre isso. Sigam o Coffinix, e se possivel me sigam também Demostenex.
Por que essa comparação importa
A maioria das discussões sobre sistemas operacionais para no nível errado. Ficam presas em benchmarks, em quantidade de software disponível, em facilidade de instalação. Essas métricas dizem pouco sobre o que realmente diferencia esses sistemas, e o que os diferencia está numa camada muito mais fundamental: a filosofia de design que guia cada decisão técnica desde a origem.
Linux, BSD e Darwin/XNU não são variações do mesmo tema. São respostas diferentes a perguntas diferentes. E entender isso exige entender não só o que cada sistema faz, mas por que foi construído dessa forma, quem o controla, e qual o custo real de cada escolha.
Parte I - O que é um sistema operacional, de verdade
Antes de comparar, é necessário estabelecer uma distinção que a maioria das pessoas ignora: a diferença entre um kernel e um sistema operacional.
Um kernel é o núcleo. Ele gerencia hardware, memória, processos, chamadas de sistema. É a camada que fica entre o hardware e o software. Mas sozinho ele não serve para nada. Para que um sistema funcione, você precisa de uma userland, as ferramentas, bibliotecas e utilitários que constroem o ambiente onde programas rodam.
O Unix clássico nasceu como um sistema completo. Bell Labs entregou kernel e userland juntos, com uma filosofia coerente permeando tudo. Quando o BSD surgiu na UC Berkeley, ele herdou essa tradição: era um sistema, não só um kernel. Quando a Apple construiu o Darwin e depois o XNU, fez o mesmo, absorveu o Mach microkernel e o BSD userland numa arquitetura integrada, com uma direção clara e um dono único.
O Linux rompeu com essa tradição de forma radical. Linus Torvalds, em 1991, não entregou um sistema. Entregou um kernel. O restante foi montado ao redor dele por atores independentes, a GNU userland, a glibc, toolchains separados, e eventualmente dezenas de distribuições empacotando tudo isso de maneiras diferentes. O que chamamos de "Linux" no dia a dia é, tecnicamente, um conjunto de projetos independentes que foram agregados em torno de um kernel comum. Isso não é detalhe, é a diferença fundamental que explica quase tudo que vem depois.
Parte II - Coesão como escolha de design
FreeBSD e o Darwin/XNU do macOS compartilham algo que o Linux estruturalmente não pode ter: um sistema base unificado.
No FreeBSD, o projeto controla kernel, libc, ferramentas base, sistema de init, pilha de rede e documentação. Tudo isso evolui junto, versionado junto, testado junto. Quando uma chamada de sistema muda no kernel, a mudança é propagada e testada em relação ao restante do sistema base antes de qualquer release. O resultado é um sistema onde você consegue rastrear o comportamento de qualquer componente até uma fonte de verdade única.
O Darwin segue uma lógica similar, porém ainda mais centralizada. A Apple controla não só o sistema base mas o hardware sobre o qual ele roda. Isso permite um nível de otimização e previsibilidade que nenhum sistema de propósito geral consegue replicar. O XNU, o kernel híbrido que mistura o microkernel Mach com componentes BSD, é desenvolvido internamente com objetivos claros: suportar as decisões de produto da Apple, agora e no futuro.
Essa coesão não é estética. Ela tem consequências práticas profundas.
Quando você audita um sistema FreeBSD, você sabe o que está auditando. O código tem uma origem, um estilo consistente, uma filosofia que permeia de ponta a ponta. O comportamento de uma chamada POSIX no userland é previsível porque o mesmo time que define a ABI do kernel é o mesmo que define como as ferramentas a usam.
No Linux, essa cadeia se quebra em vários pontos, e de formas concretas e documentadas.
A glibc e a musl, as duas implementações de libc mais usadas no ecossistema Linux, não são ABI-compatíveis entre si. Software compilado contra glibc não roda em sistemas com musl sem recompilação, e vice-versa. Isso parece um detalhe técnico até você perceber que uma parte significativa dos binários distribuídos no ecossistema Linux assume glibc, tornando musl, que é menor, mais limpa e mais auditável, um cidadão de segunda classe em grande parte dos contextos práticos.
Além disso, o próprio kernel Linux tem uma política explícita de não quebrar a ABI do kernel para o userland, mas isso não se estende ao ecossistema ao redor. Distribuições aplicam patches divergentes no kernel, na glibc e em ferramentas base. Um programa compilado numa versão de uma distribuição pode falhar em outra não porque o código do programa mudou, mas porque a combinação de versões de bibliotecas e comportamentos de sistema é diferente o suficiente para quebrar suposições implícitas. Isso não é hipotético, é o motivo pelo qual o AppImage, o Flatpak e o Snap existem. Eles são soluções para um problema que BSD e macOS não têm na mesma magnitude: a imprevisibilidade do ambiente de execução dentro do próprio ecossistema.
Containers, no contexto mais amplo, contam a mesma história. A necessidade de empacotar não só o código mas o ambiente inteiro, libc incluída, é uma resposta direta à impossibilidade de assumir consistência entre hosts Linux. Não é uma feature. É uma correção de fragmentação.
Parte III - POSIX, padrões e a questão da compatibilidade
O Unix foi, entre outras coisas, uma tentativa de criar uma interface estável entre programas e o sistema. O POSIX formalizou isso. A promessa era: escreva para a interface, e seu código roda em qualquer sistema compatível.
Na prática, BSD e Darwin honram essa promessa muito mais consistentemente do que o Linux.
Não porque o Linux ignore o POSIX, ele não ignora. Mas porque o modelo descentralizado do ecossistema Linux cria uma pressão constante por extensões, por comportamentos novos, por APIs que resolvem problemas reais mas que não existem em nenhum outro sistema. O resultado é que o Linux foi acumulando uma camada de "Linux-ismos", interfaces e comportamentos que só existem no Linux e que progressivamente se tornam dependências invisíveis de software que teoricamente deveria ser portável.
Namespaces são um exemplo direto. O mecanismo é poderoso e resolveu problemas reais de isolamento. Mas ele também introduziu exceções no comportamento de chamadas elementares como getppid(). Em um sistema BSD, getppid() retorna o PID do processo pai, sempre, de forma previsível. No Linux com namespaces, o comportamento muda dependendo de como o namespace foi configurado (o processo pode enxergar um "pai" diferente dependendo do contexto de visibilidade). Não é um bug. É uma consequência de uma feature poderosa. Mas é exatamente o tipo de exceção que se acumula ao longo do tempo e aumenta o custo cognitivo de entender e auditar o sistema.
BSD e Darwin também evoluem, também resolvem problemas novos, e fazem isso sem criar exceções desse tipo em comportamentos elementares. A diferença está em como a evolução acontece: num sistema coeso, uma mudança precisa ser reconciliada com o restante antes de ser incorporada. No Linux, a mudança pode entrar no kernel muito antes de suas implicações serem completamente entendidas pelo ecossistema ao redor.
Parte IV - Simplicidade, complexidade e o custo do systemd
O init clássico do Unix é simples até o ponto de ser chato. Você tem um processo de PID 1 que lê scripts de inicialização em ordem, sobe serviços, e faz supervisão básica. Você consegue ler o rc de um sistema BSD em uma tarde e entender o que acontece desde o boot até o sistema completo estar de pé. Não há mágica. Não há DSL. Não há dependências implícitas.
O systemd é a antítese disso.
A crítica ao systemd não é irracional nem nostálgica. Ela é sobre escopo e filosofia. O systemd não é um init, é um gerenciador de sistema que absorveu responsabilidades que no Unix clássico seriam de ferramentas independentes: resolução de DNS com systemd-resolved, gerenciamento de rede com systemd-networkd, log centralizado com formato binário proprietário via journald, montagem de sistemas de arquivo, containers leves com systemd-nspawn. Cada uma dessas funções existia antes como uma ferramenta separada, auditável de forma independente, substituível de forma independente.
O argumento a favor do systemd é real: ele resolve o problema de dependências de boot de forma que o rc não resolve em escala. Paralelizar a inicialização de centenas de serviços com dependências complexas é genuinamente difícil, e o systemd faz isso melhor do que qualquer alternativa anterior. A complexidade que ele introduz não é arbitrária, ela é proporcional ao problema que ele resolve.
Mas isso não elimina o custo. Um sistema com systemd tem uma superfície de entendimento radicalmente maior. Auditar o comportamento de boot exige conhecer a DSL de units, o mecanismo de targets, o sistema de sockets, o D-Bus, e como tudo isso interage. O comportamento real emerge da interação entre todas essas peças, não de nenhuma delas individualmente. Em produção, um sistema mais simples falha de formas mais simples. Um sistema mais complexo falha de formas que exigem mais contexto para diagnosticar.
O FreeBSD e o OpenBSD continuam com rc e mantêm sistemas que qualquer engenheiro experiente consegue entender completamente. O macOS usa launchd, que centraliza o gerenciamento de serviços de forma muito mais contida. Nenhum deles tem a escala de adoção do Linux em servidores, mas também não têm o custo cognitivo correspondente.
Parte V - O preço do controle: o lado sombrio do Darwin
O Darwin/XNU tem saído relativamente ileso das críticas nessa conversa, e isso seria injusto deixar passar.
A coesão que a Apple oferece tem um preço que vai além da falta de transparência. É um lock-in estrutural, imposto em múltiplas camadas ao mesmo tempo.
Primeiro, a ABI privada. O macOS expõe APIs públicas documentadas, mas o sistema opera internamente com uma camada de frameworks privados que a Apple usa livremente e que desenvolvedores externos não podem tocar sem risco de rejeição na App Store ou quebra silenciosa em qualquer atualização de sistema. Isso significa que o sistema real, o que a Apple usa, é diferente do sistema disponível para todos os outros. A coesão que você enxerga como usuário não é a coesão que você tem como desenvolvedor.
Segundo, a quebra de APIs entre versões. Diferente do que a narrativa de "sistema coeso" sugere, o macOS tem um histórico consistente de deprecar e remover APIs sem período de transição longo o suficiente para o ecossistema se adaptar. A transição de Carbon para Cocoa, a remoção de suporte a binários de 32 bits no Catalina, a quebra de compatibilidade com drivers de kernel extension na transição para System Extensions, cada uma dessas mudanças forçou reescritas significativas em software estabelecido. O controle central não elimina a instabilidade para desenvolvedores, ele apenas concentra o poder de decidir quando a instabilidade acontece.
Terceiro, o sandbox. O modelo de segurança do macOS moderno é genuinamente bom, mas é tão restritivo que certas classes de software simplesmente não são possíveis dentro das regras da plataforma. Ferramentas de desenvolvimento, monitores de sistema, utilitários de baixo nível: todos precisam de exceções explícitas, de perfis de entitlement aprovados pela Apple, ou simplesmente não existem na plataforma. O FreeBSD tem jails. O Linux tem namespaces e seccomp. Ambos oferecem isolamento forte sem eliminar a capacidade de construir ferramentas que operam fora do sandbox quando necessário.
O Darwin prova que controle central produz coesão. Mas também prova que coesão controlada por uma única empresa é, na prática, uma forma elegante de dependência.
Parte VI - Segurança, auditabilidade e qualidade de código
Esse é um ponto onde a comparação é mais delicada, porque os dados são ambíguos.
O Linux recebe um volume de contribuições que BSD e Darwin simplesmente não atingem. Mais olhos no código é, em princípio, bom para segurança. O problema é que mais olhos também significam mais código, mais complexidade, mais superfície de ataque, e mais dificuldade de manter qualidade consistente.
O OpenBSD é o caso mais extremo do outro lado: um time pequeno, com controle absoluto sobre o que entra no código base, com um processo de revisão rigoroso e uma cultura explícita de segurança como prioridade máxima. O resultado é um sistema com um histórico de vulnerabilidades críticas notavelmente limpo. Isso não acontece por acaso, acontece porque a maioria das vulnerabilidades nasce de complexidade não controlada, e o OpenBSD controla complexidade com mais rigor do que qualquer outro sistema relevante.
O FreeBSD fica numa posição intermediária: base de código menor e mais auditável do que o Linux, com mais abertura do que o OpenBSD. O macOS tem a vantagem de controlar toda a pilha, o que permite mitigações de segurança que precisam de coordenação entre kernel e hardware, mas paga o preço em transparência.
O Linux enfrenta um paradoxo: ele tem mais contribuições de segurança do que qualquer outro sistema, mas também tem uma superfície de ataque maior e um processo de revisão que, por necessidade, é menos rigoroso do que um projeto menor consegue manter. Vulnerabilidades recorrentes em subsistemas como BPF, io_uring e drivers de hardware mostram que volume de contribuição não é substituto de rigor arquitetural. O BPF em particular é um caso exemplar: é uma das adições mais poderosas ao kernel Linux na última década, e também uma das maiores fontes de vulnerabilidades críticas nos últimos anos, precisamente porque o poder e a superfície de ataque cresceram juntos, mais rápido do que a capacidade de auditoria acompanhou.
Conclusão - Três filosofias, três apostas, três preços
Não existe um sistema superior de forma absoluta. Existe o sistema certo para o objetivo certo, e entender isso exige ser honesto sobre o que cada um prioriza e o que cada um sacrifica.
O BSD aposta em compreensibilidade. O sistema pode ser entendido inteiramente por um engenheiro disposto a ler o código. Essa não é uma propriedade trivial, é uma escolha de design que permeia cada decisão de escopo, cada recusa de complexidade desnecessária, cada preferência por clareza sobre poder.
O Darwin aposta em controle. A Apple demonstrou que é possível construir um sistema de qualidade excepcional quando uma única entidade controla hardware, kernel, userland e distribuição ao mesmo tempo. O preço é que esse controle não é compartilhado, e qualquer um que construa sobre essa base está, em última instância, construindo sobre terreno que não é seu.
O Linux aposta em escala sem consenso. Ele não venceu por ser mais coerente. Venceu por aceitar incoerência como custo de escala, e por permitir que atores independentes empurrassem o sistema em direções que nenhum comitê central teria aprovado a tempo.
Cada uma dessas apostas cobra seu preço, inevitavelmente.
Linux otimiza para evolução. BSD otimiza para compreensão. Darwin otimiza para controle.
BSD prova que sistemas podem ser compreensíveis. Darwin prova que podem ser controlados. O Linux prova que podem crescer sem pedir permissão.
A pergunta que importa não é qual deles venceu. É qual deles você quer entender de verdade, e qual custo você está disposto a pagar por isso.
