Por que o Domo escolheu o FreeBSD

O ipfw reúne, num único conjunto de regras numeradas avaliado no kernel, filtragem stateful, NAT em kernel, classificação para o traffic shaper dummynet, marcação, policy routing (fwd), seleção de tabela de rotas (setfib, com múltiplas FIBs nativas) e listas de endereços em tabelas radix e hash. No Linux, filtro e NAT ficam no nftables e o shaping no tc, ligados por marcas de pacote: dois subsistemas, duas sintaxes. O nftables é excelente — a diferença é operacional: uma política completa é uma sequência de regras que se aplica e se troca de forma atômica.

Uma definição de pipe com máscara por endereço instancia um limitador independente por cliente; os escalonadores WF2Q+, QFQ, FQ-CoDel e FQ-PIE e os controles ativos de fila CoDel e PIE executam no kernel, e banda, atraso e tamanho de fila mudam em tempo real sem interromper o tráfego. O tc do Linux tem HTB e CAKE, com AQM em pé de igualdade; o RouterOS resolve o mesmo caso com o PCQ. No FreeBSD isso é mecanismo nativo do kernel, documentado, sem dependência de fornecedor.

O netgraph é um framework nativo em que cada função de enlace é um nó de um grafo — Ethernet, PPPoE, PPP, L2TP, VLAN, bridge, NAT, exportação NetFlow, limitador por sessão — conectados por hooks. No servidor PPPoE e L2TP do Domo, o plano de controle (autenticação, negociação) roda fora do kernel; o caminho de dados de cada assinante fica inteiro dentro dele. O Linux também processa PPPoE/L2TP no kernel e tem concentradores maduros; o que o netgraph acrescenta é composição: qualquer encapsulamento se conecta a qualquer outro sem código novo.

Desde o FreeBSD 4.1, o kqueue é um único mecanismo de notificação para sockets, arquivos, mudanças em diretórios, ciclo de vida de processos, sinais, timers e I/O assíncrono, com registro e coleta em lote numa só chamada e compatibilidade preservada desde então. O epoll do Linux resolve o caso central com desempenho equivalente, complementado por inotify, signalfd e timerfd; o io_uring vai além em I/O assíncrono. Para os serviços de um roteador, uma API única e estável há 25 anos significa daemons mais simples e menos superfície de erro.

No FreeBSD, o núcleo da pilha TCP — processamento de segmentos, saída, recuperação de perdas e temporizadores — é um bloco de funções intercambiável: a pilha padrão e a RACK (RACK-TLP com pacing de alta precisão) coexistem no mesmo kernel e são escolhidas para o sistema ou por conexão, sem reiniciar, valendo para conexões novas; os algoritmos de congestionamento (CUBIC, padrão desde o 14, NewReno, DCTCP) são módulos. O Linux tem uma única implementação TCP, e ela é referência: RACK-TLP é padrão lá, o BBR nasceu lá e um algoritmo novo pode até ser carregado como programa eBPF. Em desempenho os dois competem de perto; o diferencial é arquitetural — e só afeta o tráfego que termina na própria máquina (VPN, proxy, servidor de arquivos, gerência). O que o roteador encaminha não passa pela pilha TCP.

Os drivers das placas de classe servidor (Intel, Chelsio, NVIDIA/Mellanox, Broadcom) fazem parte da árvore do FreeBSD, com participação dos fabricantes, e saem junto com o kernel — o mesmo vale para o Linux mainline, então isso, sozinho, não é diferencial. O particular do FreeBSD é o iflib: os drivers Intel, o bnxt e o vmx compartilham um caminho comum de filas múltiplas, MSI-X, afinidade fila→CPU por RSS e integração nativa com o netmap, com ajustes uniformes, de modo que uma correção nessa camada chega a todos de uma vez (Chelsio e Mellanox usam pilhas próprias). O Linux suporta muito mais hardware, recebe placas novas antes, tem o ethtool como ajuste uniforme em todos os drivers e XDP/AF_XDP nativo. No nicho de roteador com placas de servidor, a vantagem do FreeBSD é a coerência da pilha, não disponibilidade ou desempenho de drivers.

O OpenZFS faz parte da árvore do FreeBSD (na base desde o 7.0; código do projeto OpenZFS em sys/contrib/openzfs desde o 13.0): kernel, módulo e ferramentas saem do mesmo commit e são testados no mesmo ciclo, e o instalador destaca root-on-ZFS como opção padrão desde o 13.0, já com boot environments e compressão lz4. Quando o Domo é instalado em ZFS, datasets, snapshots, replicação e boot environments usam esse mesmo ZFS. O Linux dispõe do mesmo OpenZFS, com recursos praticamente idênticos e mais instalações em números absolutos (Proxmox, TrueNAS e Ubuntu o entregam casado com o kernel); a diferença é de integração — fora da árvore do kernel por licença, no caminho DKMS cada versão suporta uma janela de kernels. O ganho é coerência de versões, não imunidade a incidentes.

O ZFS é CDDL, incompatível com a GPLv2 na leitura da FSF, da Software Freedom Conservancy e dos mantenedores do kernel; por isso o OpenZFS não entra no kernel Linux e é compilado como módulo externo contra APIs internas sem garantia de estabilidade — quando o Linux 5.0 (2019) deixou de exportar as funções de FPU não marcadas GPL, o módulo perdeu SIMD em checksums e RAID-Z até reimplementar isso por conta própria. No FreeBSD, cuja licença não conflita com a CDDL, o mesmo OpenZFS vive na árvore e não existe kernel sem o ZFS correspondente. Isso não torna o ZFS no Linux imaturo — Ubuntu, Proxmox e TrueNAS SCALE são plataformas consolidadas; a diferença é que a integração é trabalho recorrente da distro, não do projeto do kernel. E estar na árvore não imuniza contra bugs do próprio ZFS: o bug de block cloning do OpenZFS 2.2.0 atingiu o FreeBSD 14.0 igualmente.

O checksum de cada bloco (fletcher4 por padrão; sha256, skein e blake3 disponíveis) fica no ponteiro do bloco pai, numa árvore de Merkle até o uberblock, e toda leitura vinda do disco é conferida. Em pools com redundância (espelho, RAID-Z ou cópias múltiplas), um bloco que não bate é lido da outra cópia, devolvido correto e reescrito no lugar, com o evento contado no estado do pool; em disco único, a corrupção é detectada e reportada, mas não corrigida. O btrfs tem o mesmo modelo dentro da árvore do Linux e é sólido em espelhamento; ext4 e XFS verificam só metadados, e um espelho md/LVM não percebe divergência silenciosa entre os lados sem a camada dm-integrity. Em servidores de borda com SSDs de origem variada e sem climatização, corrupção silenciosa deixa de ser silenciosa.

Um boot environment é um clone do dataset raiz criado a partir de um snapshot: instantâneo, ocupando só os blocos que divergirem. O bectl, na base desde o FreeBSD 12, cria, monta, ativa e destrói ambientes; o loader do FreeBSD traz um leitor de ZFS mantido no mesmo repositório e ciclo de release, lê o bootfs, mostra os ambientes no menu de boot e carrega kernel e módulos direto do pool — sem um pool de /boot com recursos reduzidos, como o GRUB exige nos guias oficiais de root-on-ZFS para Debian e Ubuntu. Fora do pool fica só o binário do loader, a atualizar após um upgrade de versão. O Linux alcança o equivalente com snapper + btrfs (openSUSE), rpm-ostree, ZFSBootMenu ou imagens A/B (OpenWrt, VyOS) — soluções de cada distro, não do sistema.

Snapshots ZFS são criados em tempo praticamente constante e só passam a ocupar espaço quando blocos originais são sobrescritos; a replicação (zfs send -i | zfs receive) transfere para outro servidor apenas os blocos alterados desde o último snapshot comum, sem varrer a árvore de arquivos, com propriedades e snapshots filhos preservados no modo recursivo. É o mesmo OpenZFS do Linux; o equivalente na árvore do Linux é o btrfs send/receive e, para replicação síncrona em bloco, o Linux conta com DRBD e Ceph, sem paralelo de uso corrente no FreeBSD. Trata-se de réplica assíncrona — o destino fica defasado até o intervalo do último snapshot — e o failover do papel de roteador continua sendo CARP/VRRP. Onde pesa de verdade é no papel de servidor (VMs, bancos, arquivos) e na volta de atualizações; o RouterOS não oferece snapshot nem replicação de sistema de arquivos.

Particionamento (gpart), rótulos (glabel), espelhamento (gmirror), cifra (geli) e multipath são classes de um único framework do kernel, o GEOM (desde 2003): cada camada consome um provedor e expõe outro, com a mesma sintaxe de ferramentas, reconhecidas no boot pelos próprios metadados, sem initramfs — o ZFS faz espelho e RAID-Z internamente e usa o GEOM apenas como fonte de discos. O Linux cobre as mesmas funções com device-mapper, md e LVM2, igualmente empilháveis, e em pontos vai além: write-intent bitmap no md, multipath com ALUA, thin provisioning e cache no LVM, desbloqueio de disco cifrado por TPM2. A vantagem do FreeBSD é coesão e uma cadeia de boot mais curta de depurar, não capacidade; para um roteador com um único SSD pesa pouco, e em servidores o GEOM importa sobretudo como base sob o ZFS.

O bhyve faz parte do sistema base desde o FreeBSD 10 (2014): o módulo vmm usa exclusivamente as extensões de hardware x86 (Intel VT-x/EPT, AMD-V/NPT) e cada VM é um processo em espaço de usuário que implementa os dispositivos — VirtIO, NVMe, AHCI, e1000, framebuffer com VNC — e entra em modo de capacidade do Capsicum por padrão. O Domo cria VMs com firmware UEFI, importa discos de outros hipervisores e roda FreeBSD, Linux, Windows (com os drivers VirtIO) e outros BSDs. Comparação honesta: o KVM também roda só com extensões de hardware e é o hipervisor aberto mais completo — migração ao vivo, virtualização aninhada, vGPU/SR-IOV, snapshots em produção —, coisas que o bhyve não faz. O que o Domo resolve é o caso comum de um servidor de borda: uma VM auxiliar no mesmo equipamento e na mesma interface, com um hipervisor pequeno, sob licença BSD e mantido junto com o resto do sistema.

Jails são o isolamento nativo do FreeBSD desde 2000: um objeto do kernel ao qual toda credencial de processo fica ligada, com raiz, hostname e usuários próprios; o que o root da jail pode fazer é definido pelo kernel e pelos parâmetros allow.*, não pela configuração de um runtime externo. Com VNET (no kernel padrão desde o FreeBSD 12), cada jail recebe pilha de rede própria — interfaces, tabela de rotas e instância de firewall — e limites de CPU, memória e I/O via RCTL. O Linux entrega isolamento equivalente compondo namespaces, cgroups, capabilities, seccomp e LSM: mais flexível, com contabilidade mais fina e o ecossistema OCI, além de user namespaces e seccomp, que jails não têm — ambos os lados já tiveram avisos de escape. Num roteador, DNS, DHCP, VPN e proxy em jails VNET separadas ganham rota e regras próprias sem instalar nada além da base.

Um processo que chama cap_enter perde, de forma irreversível, o acesso aos namespaces globais — não abre arquivos por caminho, não sinaliza outros processos nem inicia conexões — e passa a operar só sobre descritores que já possuía, cada um limitado a direitos explícitos. Programas da base mais expostos a entrada hostil — tcpdump, dhclient, ping, a pré-autenticação do sshd, o próprio bhyve — já rodam assim sem configuração do operador; serviços instalados de pacotes, em geral, não. O Linux confina por outro caminho — seccomp-bpf, Landlock, namespaces, SELinux/AppArmor, hardening do systemd —, políticas aplicadas de fora, habilitadas por padrão em RHEL e Ubuntu e válidas para qualquer programa. A diferença do Capsicum é ser um modelo de capacidades construído dentro do programa, sem política externa a manter, cobrindo só quem o adotou. É defesa em profundidade, não garantia: um exploit no analisador de pacotes fica restrito aos descritores que o processo já tinha.

Kernel, biblioteca C, utilitários de rede (ifconfig, route, netstat, ipfw), o compilador Clang/LLVM e o sistema de build vivem em um único repositório. Uma release — no Domo, o FreeBSD 15.0-RELEASE — é compilada de um mesmo commit, passa pela mesma integração contínua e pela suíte de testes do projeto, e sai com um só número de versão, um só conjunto de erratas e de avisos de segurança. O ipfw que o Domo executa e o módulo ipfw do kernel são sempre a mesma revisão. Distribuições sérias integram muito bem — mas integram: dezenas de projetos, cada um com o seu ciclo.

Na série stable/N o FreeBSD adota a política de preservar a interface binária do kernel entre versões menores: mudanças que afetem módulos são evitadas e, quando inevitáveis, anunciadas e marcadas. Isso vale para os subsistemas nativos (rede, ipfw, criptografia, bhyve, ZFS); a camada LinuxKPI, de drivers portados, fica fora. No userland, as opções COMPAT_FREEBSD e o versionamento de símbolos mantêm programas antigos rodando após um upgrade de versão. O Linux não oferece ABI para módulos por decisão explícita — num appliance, isso significa mais custo para o fabricante emitir cada correção de kernel, não algo que o operador veja.

O FreeBSD publica por escrito, no dia do lançamento, até quando cada série recebe correções de segurança e erratas: a série 14 até 30 de novembro de 2028 (cinco anos) e, a partir do 15 — lançado em dezembro de 2025 —, a janela passou a quatro anos, com a série 15 suportada até 31 de dezembro de 2029. A cadência é uma versão major a cada dois anos e uma minor a cada seis meses, com kernel e userland atualizados juntos; cada minor deixa de receber correções três meses após a seguinte, então é preciso acompanhar as minors ao longo da série. Essa garantia cobre o sistema base; pacotes de terceiros seguem o ciclo dos seus projetos, como em qualquer sistema. Distribuições Linux corporativas oferecem janelas iguais ou maiores — RHEL dez anos, Ubuntu LTS cinco (dez com Pro), Debian cerca de cinco — cobrindo também os próprios pacotes. O que o FreeBSD oferece é um calendário único e público para a base, sem assinatura, com histórico de cumprir as datas.

O sistema base (kernel, biblioteca C, ifconfig, /etc) e o software de terceiros ocupam diretórios distintos, por convenção documentada e imposta pela árvore de ports: a base em /bin, /sbin, /usr/bin, /usr/lib e /etc; pacotes em /usr/local, com configuração em /usr/local/etc. A base é atualizada como uma unidade, com rollback — por freebsd-update ou, a partir do 15, por pkgbase, um repositório separado do mesmo gerenciador. Atualizar o servidor de banco de dados não sobrescreve a base, e atualizar a base não toca em /usr/local; a separação é de arquivos, não de ABI — um upgrade de versão major exige reinstalar os pacotes. Distros Linux convencionais mantêm kernel, glibc e aplicações no mesmo /usr e no mesmo banco de pacotes (com proteção contra conflito), e distros imutáveis e appliances como OpenWrt e RouterOS obtêm fronteira equivalente, muitas vezes com atualização atômica da imagem — por desenho da distro, não do sistema.

A base do FreeBSD — kernel e userland, incluindo OpenSSL e OpenSSH embutidos — tem um único processo de avisos de segurança: os FreeBSD Security Advisories, assinados pelo Security Officer e publicados junto com o patch e a atualização binária para todas as releases suportadas; para os pacotes, o pkg audit compara o inventário instalado com o banco VuXML. Distribuições Linux maduras (Debian, RHEL, SUSE, Ubuntu) oferecem cobertura equivalente num feed único, com ferramentas próprias e, no kernel, até livepatch sem reinício. A vantagem do FreeBSD aqui é a simplicidade de um conjunto pequeno e coeso, não exclusividade — e é o fornecedor do appliance, não o operador, quem acompanha esse canal e empacota a correção.

O FreeBSD entrega, instaladas na própria máquina e geradas da mesma árvore de código da versão em uso, páginas de manual para o sistema base inteiro: utilitários, arquivos de configuração, guias de ajuste e segurança, drivers de rede na seção 4 e as APIs internas do kernel na seção 9 — estas sem equivalente instalado por padrão em distribuições Linux. A profundidade varia por driver, e o Handbook é um documento único, mas contínuo, não versionado por release. No Linux a documentação é forte por componente — as man pages de iproute2, nftables e systemd acompanham o pacote instalado, e o Arch Wiki e a documentação da Red Hat são referências de primeira linha; o que não existe é um conjunto único que descreva a combinação exata de kernel, drivers e userland que está rodando. É essa coerência entre o instalado e o documentado, e não qualidade superior de texto, que o FreeBSD oferece a quem dá suporte ao equipamento.

O código do projeto FreeBSD é licenciado sob a BSD de duas cláusulas: usar, modificar e redistribuir, em fonte ou binário, reproduzindo o aviso de copyright, as condições e a isenção de garantia — sem obrigação de entregar modificações nem de adotar a mesma licença. É essa compatibilidade que permite o ZFS (CDDL) integrado ao kernel, impossível no Linux. A base não é 100% permissiva — ZFS e DTrace são CDDL, LLVM e OpenSSL têm licença permissiva própria — e os pacotes de terceiros trazem cada um a sua licença, com o mesmo trabalho de gestão que teriam num Linux. Sobre a GPLv2 do kernel Linux, precisão: ela não impede vender nem obriga a abrir programas que apenas usam o kernel; exige que quem distribui binários GPL forneça aos destinatários o código correspondente, inclusive modificações — obrigação já cobrada judicialmente de fabricantes de roteadores e com a qual MikroTik, Ubiquiti e Cisco convivem sem prejuízo. Para quem compra, a GPL garante acesso às modificações do kernel que recebe; sob BSD, essa garantia depende da política do fornecedor.

O FreeBSD tem histórico verificável em produtos de carga pesada: os servidores Open Connect da Netflix (cerca de 800 Gb/s de vídeo TLS por servidor demonstrados em 2022), os firewalls pfSense e OPNsense, o Junos OS clássico da Juniper, o ONTAP da NetApp, o OneFS da Dell PowerScale e o NetScaler — e parte dessas empresas devolve código: o bhyve nasceu na NetApp; o kTLS, o sendfile assíncrono e as otimizações NUMA da pilha TCP vieram da Netflix. Dito com a mesma clareza: o Linux é dominante em todas essas classes (RouterOS, IOS-XE, EOS, PAN-OS, FortiOS, VyOS, OpenWrt, além das grandes CDNs), recebe muito mais investimento corporativo, e houve migrações no sentido contrário — o Junos Evolved e o TrueNAS, que deixou o FreeBSD em 2024–2025. O que esse histórico prova não é superioridade: é que construir um roteador ou servidor sobre FreeBSD é uma escolha conservadora e de baixo risco.

A paridade entre os gerenciadores do Domo vem da arquitetura: a lógica de cada domínio vive em um único módulo no equipamento, e as interfaces apenas o chamam — o mesmo padrão que RouterOS, VyOS e OpenWrt adotam sobre Linux. O que o FreeBSD acrescenta é reduzir as partes móveis a validar: kernel e userland base (ipfw, ifconfig, route, bhyve, OpenZFS) saem da mesma árvore, na mesma release, identificáveis com precisão. No Linux, kernel, iproute2, nftables e init são projetos separados que a distribuição integra e valida — trabalho que Debian stable, RHEL e Ubuntu LTS fazem bem, e o kernel Linux tem a regra firme de não quebrar o userspace; a diferença é que, no FreeBSD, kernel e “distro” são um só upstream. Ferramentas vindas de pacotes não herdam essa garantia e precisam ser fixadas e testadas à parte, como em qualquer produto.