Um ano de patrocínio ao desenvolvimento do FreeBSD

 (daemonology.net)
2 pontos por GN⁺ 2025-06-07 | 1 comentários | Compartilhar no WhatsApp
  • Em uma situação em que a manutenção do FreeBSD/EC2 e a engenharia de releases competiam pelo tempo voluntário de uma única pessoa, o patrocínio de um ano da Amazon tornou possível avançar simultaneamente na operação de releases e em melhorias da plataforma EC2
  • Embora o patrocínio fosse nominalmente de 40 horas mensais via GitHub Sponsors, o trabalho real ficou em média em 50 horas por mês, dividido aproximadamente em 20/20/10 horas entre issues do EC2, condução de releases e outras tarefas de engenharia de releases
  • Ao longo de um ano, foram gerenciados os releases FreeBSD 13.4, 14.2, 13.5 e 14.3, em paralelo com trabalhos prioritários como o tratamento de sinais de desligamento no AWS Graviton e o hotplug de dispositivos no EC2
  • Para identificar regressões de desempenho de boot, foram benchmarkadas builds semanais de AMIs EC2 desde 2018, encontrando e corrigindo causas de atraso ligadas ao tamanho do disco raiz, ao seeding de entropia via EFI, a transaction groups do ZFS e a mudanças de IPv6 no IMDSv2
  • Mesmo após o fim do patrocínio, as funções continuam, mas o tempo disponível diminui para corrigir diretamente problemas às vésperas dos releases ou para seguir avançando na lista de recursos do EC2

Gargalos antes do patrocínio e alocação de tempo

  • A manutenção do FreeBSD/EC2 vinha desde 2010, quando o FreeBSD foi inicializado pela primeira vez no Amazon EC2, e em novembro de 2023 foi acrescentado também o papel de líder de engenharia de releases do FreeBSD
  • Apenas com pequenos apoios da Antithesis e do Patreon do FreeBSD/EC2, era difícil dar conta dos dois papéis
    • A lista de recursos a implementar ficou parada
    • Ao encontrar comportamentos anômalos, aumentavam os casos adiados por falta de tempo para investigar
    • No início de 2024, cresceu a preocupação de que seria difícil atuar como um “bom dono” da plataforma FreeBSD/EC2
  • Em abril de 2024, quando a Amazon encontrou uma pessoa responsável com orçamento, avançaram as discussões sobre cronograma, escopo e procedimentos, e a Amazon decidiu patrocinar por um ano via GitHub Sponsors
  • O patrocínio cobria 40 horas mensais combinando engenharia de releases do FreeBSD e desenvolvimento do FreeBSD/EC2
    • Foi comunicado que, por haver dependências entre os dois trabalhos, patrocinar apenas um deles não seria uma abordagem realista
    • A dedicação real aumentou para cerca de 50 horas mensais em média
    • Em média, foram 20 horas em issues específicas do EC2, 20 horas na condução de releases do FreeBSD e 10 horas em outros trabalhos relacionados à engenharia de releases, embora houvesse grande variação mensal

Operação de releases trimestrais e melhorias de build

  • Seguindo o calendário de releases trimestrais do FreeBSD anunciado em julho de 2024, foram gerenciados 4 releases ao longo de um ano
    • FreeBSD 13.4: setembro de 2024
    • FreeBSD 14.2: dezembro de 2024
    • FreeBSD 13.5: março de 2025
    • FreeBSD 14.3: release previsto para 10 de junho de 2025
  • Cada release incluiu incentivar merges de código, aprovar ou rejeitar solicitações de merge, coordenar com outras equipes, criar e testar imagens, redigir anúncios e corrigir problemas nas builds de release
    • Normalmente são gerados 3 Betas, 1 Release Candidate e o Release final
    • A maior parte do trabalho se concentra no mês anterior ao release, ou seja, no segundo mês de cada trimestre, o “Beta Month”
    • O FreeBSD 13.5 consumiu 33,5 horas, e o FreeBSD 14.2 consumiu 79 horas
    • À medida que uma branch estável avança para a parte final de seu ciclo, tende a haver menos itens quebrando, e o volume de trabalho de release também diminui
    • O FreeBSD 14.1 não foi acompanhado, mas o tempo de engenharia de releases provavelmente ficou perto de 100 horas, e o FreeBSD 15.0 pode exigir muito mais do que isso
  • Na engenharia de releases geral, também foi feita a paralelização das builds de release
    • Com o aumento do número de AMIs EC2, o tempo para instalar o FreeBSD nas imagens de VM passou a representar uma parcela maior do que a build em si
    • O código de release foi paralelizado, mas surgiram falhas esporádicas de build; como uma build completa de release levava cerca de 24 horas, era difícil isolar a causa
    • A causa final era a ausência de uma única linha no Makefile para criar um diretório antes de instalar arquivos
    • Após a correção, a build de release caiu de cerca de 22 horas para cerca de 13 horas, e também se tornou possível expandir os flavours de AMI EC2 que vinham sendo adiados por causa do tempo de build
  • Problemas de reprodutibilidade de build passaram a ser verificados regularmente usando EC2
    • Durante os testes semanais de imagens snapshot, uma instância EC2 é iniciada para construir sua própria AMI
    • As imagens de disco geradas são comparadas com as imagens originais usando diffoscope
    • Os testes regulares revelaram vários issues; alguns foram corrigidos diretamente e outros foram encaminhados a outros desenvolvedores

Tratamento de energia no Graviton e hotplug no FreeBSD/EC2

  • Os principais recursos que a Amazon solicitou como prioridade no FreeBSD/EC2 foram um power driver para instâncias AWS Graviton e hotplug de dispositivos
  • O driver de energia do Graviton trata o caminho pelo qual a API do EC2 informa ao sistema operacional que ele deve desligar
    • Sem esse recurso, o FreeBSD ignora o sinal de desligamento e, alguns minutos depois, o EC2 atinge timeout e corta a energia virtual
    • O “botão de energia” em sistemas Graviton é um pino GPIO, e os detalhes ficam no objeto ACPI _AEI
    • Foi adicionado código para localizar essa informação no ACPI e passar as configurações ao driver do controlador GPIO PL061
    • Quando o pino GPIO é asserted, o controlador gera uma interrupção, ocorre um evento ACPI de “power button” e isso leva ao desligamento do sistema
  • As tabelas ACPI fornecidas pelo EC2 especificam que esse pino GPIO deve ser configurado como “Pull Up”, mas o controlador PL061 não tem resistores pullup/pulldown
    • O Linux ignorava silenciosamente a falha de configuração do GPIO, então o problema não aparecia
    • O FreeBSD desativava o dispositivo após a falha de configuração
    • Embora se espere que o bug do EC2 seja corrigido em sistemas Graviton futuros, por enquanto as AMIs FreeBSD/EC2 incluem a quirk ACPI_Q_AEI_NOPULL para ignorar a flag GPIO PullUp do objeto _AEI
  • Hotplug, especialmente hot unplug, exigiu mais trabalho porque diferentes tipos de instâncias EC2 tinham problemas distintos sobrepostos
    • Alguns sistemas Graviton vazavam reservas de IRQ virtual durante o PCI attach; depois de 67 operações de attach/detach de volumes EBS, as IRQs se esgotavam e o kernel do FreeBSD entrava em panic
      • A causa era o código legado de roteamento de interrupções PCI, e foi adicionada uma configuração de boot loader para desativar esse código no EC2
    • Alguns sistemas Graviton usavam o estado de energia do dispositivo PCI como sinal para decidir se o OS havia terminado de usar o dispositivo e estava pronto para o eject
      • Isso é considerado um bug do EC2, e atualmente a quirk ACPI_Q_CLEAR_PME_ON_DETACH altera alguns bits dos registradores de gerenciamento de energia PCI antes do eject
    • Em instâncias EC2 x86 e Graviton de geração mais recente, o driver nvme do FreeBSD gerava panic após um PCIe unplug
      • Esse problema foi encaminhado ao mantenedor do driver nvme
    • Em algumas instâncias EC2 x86 e Graviton, depois do eject ficava um dispositivo “ghost” no barramento PCI, impedindo o attach de novos dispositivos
      • O firmware Nitro gerencia o barramento PCI e os dispositivos PCI de forma assíncrona, criando uma janela em que o dispositivo já foi unplugged, mas o barramento PCI ainda é reportado como existente por alguns ms
      • O Linux escaneia o barramento periodicamente e geralmente perde essa corrida, mas o FreeBSD reescaneia o barramento PCI imediatamente após o detach e por isso via o ghost com frequência
      • Atualmente, a quirk ACPI_Q_DELAY_BEFORE_EJECT_RESCAN adiciona um atraso de 10 ms antes de reescanear o barramento PCI após o sinal de eject
  • O PCIe exige um atraso de 5 segundos depois que o botão “attention” é pressionado para solicitar eject do dispositivo, e uma segunda pressão do botão cancela a solicitação de eject
    • No EC2, não há ninguém pressionando um botão físico nem mecanismo para pressionar novamente o botão virtual, portanto esse atraso é desnecessário
    • Foi adicionado um tunable do boot loader para definir o timeout como 0 no EC2
  • Com um script de teste de hotplug, é possível iniciar uma instância EC2, conectar e desconectar repetidamente volumes EBS via API do EC2 e verificar se o FreeBSD completa 300 operações consecutivas de attach/detach
    • No futuro, caso haja acesso antecipado a tipos de instância EC2, isso poderá ser usado para verificar se o hotplug funciona corretamente

Rastreamento de regressões de desempenho de boot e expansão das AMIs

  • Além das duas tarefas de maior prioridade da Amazon, cerca de metade do tempo dedicado especificamente ao EC2 foi usada em outros problemas do FreeBSD/EC2
  • No fim de 2023 e início de 2024, instâncias FreeBSD/EC2 às vezes demoravam mais do que o esperado para inicializar, e nos testes semanais de snapshots foi necessário aumentar o tempo de espera antes de tentar conectar via SSH após iniciar a instância
  • Para lidar com o problema de desempenho, foram benchmarkados os tempos de boot das builds semanais de AMIs EC2 desde 2018
    • Nesse processo, mais de 10 mil instâncias EC2 foram executadas
    • Começaram a ser gerados os gráficos de desempenho de boot do FreeBSD
    • A nova coleta de dados e a atualização dos gráficos foram incorporadas ao processo semanal de testes de snapshots
  • Várias causas de atraso no boot foram encontradas e corrigidas
    • A partir da primeira semana de 2024, o boot do FreeBSD ficou cerca de 3 vezes mais lento, e a causa foi rastreada até um commit que aumentou o tamanho do disco raiz de 5 GB para 6 GB
      • Após verificação do lado da Amazon, aumentar o disco raiz para 8 GB restaurou o desempenho anterior
    • Na família Graviton 2, o boot ficou mais longo por causa de um problema de seeding de entropia do kernel
      • O kernel do FreeBSD interrompe o boot até coletar mais entropia quando não há entropia suficiente para geração segura de números aleatórios
      • Já havia código para receber uma semente segura do firmware Nitro via boot loader EFI, mas ele não era executado no EC2, e no Graviton 2 a solicitação de 2048 bytes era muito lenta
      • A solicitação que estava no código Lua do menu de boot foi movida para o local Lua apropriado do boot loader, para ser executada independentemente de o menu estar desativado ou não
      • Ao receber 64 bytes de entropia EFI e expandi-los com PBKDF2 para corresponder à entrada de 2048 bytes da API, o tempo de boot do FreeBSD arm64/base/UFS caiu de cerca de 25 segundos para cerca de 8 segundos
    • Imagens ZFS demoravam mais para inicializar do que UFS, e a magnitude do atraso variava conforme a quantidade de dados no disco, não o tamanho do disco
      • O makefs colocava tudo em um único transaction group e, ao fazer attach do ZFS, o sistema percorria e validava os transaction groups recentes, lendo e processando todos os metadados de arquivos do disco
      • Mark Johnston resolveu o problema fazendo o filesystem registrar transaction groups mais altos, para que um único transaction group não fosse considerado “recente”
      • O tempo de boot das imagens ZFS caiu de cerca de 22 segundos para cerca de 11 segundos
    • Em dezembro de 2024, após a inclusão de suporte a IPv6 no port net/aws-ec2-imdsv2-get, o problema de boot foi detectado rapidamente
      • Esse port fornece uma interface de linha de comando para o EC2 Instance MetaData Service
      • Ele tentava IPv6 primeiro, mas a configuração padrão de instância do IMDS era IPv4-only, e o timeout TCP padrão de 75 segundos também permanecia inalterado
      • Após a correção, ele passou a tentar IPv4 primeiro e reduziu o timeout para 100 ms
  • Os flavours de AMI do FreeBSD também foram expandidos
    • Antes, havia apenas base e cloud-init
    • A AMI small remove debug symbols, LLDB, bibliotecas de 32 bits, testes do FreeBSD, Amazon SSM Agent e AWS CLI, reduzindo o uso de disco de cerca de 5 GB para cerca de 1 GB
    • A AMI builder fornece as AMI Builder AMIs do FreeBSD, que permitem aos usuários criar facilmente AMIs FreeBSD personalizadas
  • Com a expansão das builds semanais de snapshots para combinações de 4 flavours de AMI, 2 filesystems, 2 arquiteturas e 3 versões do FreeBSD, imagens antigas e snapshots EBS relacionados foram limpos
    • A conta AWS de engenharia de releases do FreeBSD é patrocinada pela Amazon, mas os custos recaem sobre alguém
    • Foi escrito um shell script que permitiu remover 336 TB de snapshots EBS

Trabalhos restantes e limitações após o fim do patrocínio

  • Além dos grandes projetos, vários trabalhos menores continuaram
    • Correção de quebras de build encontradas nas builds semanais de snapshots
    • Revisão de patches do driver ENA
    • Apoio a Dave Cottlehuber para adicionar a funcionalidade de construir OCI Containers e enviá-los ao repositório
    • Melhoria da ferramenta bsdec2-image-upload para lidar de forma mais suave com erros internos da AWS
    • Relato de um problema de segurança da AWS encontrado por acaso
  • Mesmo após o fim do patrocínio, os papéis de líder de engenharia de releases do FreeBSD e mantenedor da plataforma FreeBSD/EC2 continuam
    • O FreeBSD 15.0 deve chegar em dezembro
    • Em 2026, devem vir 14.4, 15.1, 14.5 e 15.2
  • Com a redução do tempo disponível, fica difícil corrigir diretamente problemas às vésperas dos releases
    • Recursos que chegam tarde têm maior probabilidade de serem removidos do que corrigidos a tempo do release
    • O fato de OCI Containers terem podido ser incluídos a partir do FreeBSD 14.2 se deve ao tempo patrocinado, que permitiu garantir que as peças necessárias entrassem de forma íntegra
  • No lado do EC2, os testes de regressão de desempenho de boot já estão montados, o que aumenta a chance de detectar problemas relacionados, mas a lista de implementação de recursos pode ficar parada sem tempo adicional
    • Expansão automática do filesystem ao expandir volumes EBS
    • Melhor configuração automática de múltiplas interfaces de rede e de hotplug de interfaces de rede
    • AMIs rolling “pre-patched”
    • Site para gerar arquivos EC2 user-data para instalação de pacotes, execução de daemons etc.
    • Retomada do trabalho em FreeBSD/Firecracker e transformação em plataforma suportada
  • O patrocínio da Amazon foi uma oportunidade muito maior do que a maioria dos desenvolvedores open source recebe; junto com a tristeza pelo fim do patrocínio, fica a gratidão pelos resultados alcançados nesse período

Leituras relacionadas

1 comentários

 
GN⁺ 2025-06-07
Comentários do Hacker News

  • Legal. A partir de hoje, adicionamos FreeBSD à página de downloads do ziglang.org, para que usuários de FreeBSD possam obter builds do branch master gerados automaticamente pelo CI
    Agora ele é suportado como alvo de cross-compilação de primeira classe, incluindo linkagem com libc, então coisas como zig cc -o hello hello.c -target riscv64-freebsd também são possíveis
    Se houver dependências em C/C++, dá para trazê-las para o sistema de build do Zig e compilá-las, então acho que até projetos bastante complexos poderão ser cross-compilados para FreeBSD com facilidade. Espero que isso ajude mais projetos a adicionar suporte a FreeBSD e testes em CI

    • A cross-compilação do Zig é excelente, e é bom ver FreeBSD entrando na lista de alvos suportados
    • O Zig tem uma licença amigável ao BSD, e o FreeBSD já inclui LLVM no sistema base, então fico curioso se um dia o Zig também entrará no sistema base
      Seria bom ter uma alternativa ao C reconhecida oficialmente

  • Há alguns trechos bem interessantes aqui
    “Desde a primeira semana de 2024, o processo de boot do FreeBSD de repente ficou cerca de 3 vezes mais lento. Fazendo uma busca binária nos commits, a causa foi um commit que aumentava o tamanho do disco raiz de 5 GB para 6 GB. Por quê? Perguntei a conhecidos na Amazon, e a resposta ficou em algum lugar entre ‘magia’ e ‘você realmente não quer saber’; o importante é que, ao aumentar o disco raiz para 8 GB, o desempenho voltou ao nível anterior”

    • O limite de tamanho de objeto original do S3 era 5 GB, e isso também consta em um post de 2006: https://aws.amazon.com/blogs/aws/amazon_s3/
      Não sei se isso tem relação com o penhasco de desempenho observado
    • Mesmo assim, agora eu realmente quero saber
    • Fico imaginando quanto tempo levou para fazer essa busca binária do problema. Será que a cada vez ele compilava a imagem e reiniciava a VM?

  • Também há muito trabalho no lado de notebooks, e li que a BSD Foundation investiu 750 mil dólares nisso
    Inclui implementações como o estado de economia de energia S0ix, e o projeto pode ser visto aqui: https://github.com/FreeBSDFoundation/proj-laptop

    • Sim, há muito trabalho em andamento. Eu só escrevi sobre o trabalho que eu estava fazendo ;-)

  • Tenho muito respeito pelo cperciva
    Não sei como ele consegue fazer tudo isso junto com o Tarsnap

    • A partir de certo ponto, dá para comprar tempo com dinheiro. É como decidir se você mesmo conserta uma torneira vazando ou chama um encanador, ou se você mesmo refaz o drywall do porão depois que eletricistas o arrancaram, ou chama profissionais
      Para ser justo, parte do tempo gasto aqui saiu do Tarsnap, mas muito menos do que se poderia imaginar

  • Eu esperava que a Amazon gastasse e contribuísse mais, mas basicamente parece que ela só quer pagar pelo suporte mínimo ao FreeBSD
    A Amazon nem aparece na lista de apoiadores do FreeBSD [1], o Google patrocinou apenas 9 mil dólares no ano passado, e a Apple também não aparece. A Microsoft ao menos está na lista, então dá para reconhecer. A Meta/Facebook também está ausente
    Essas empresas usam FreeBSD e OpenBSD e continuam se beneficiando deles, então eu esperava que basicamente fizessem doações todos os anos
    [1] https://freebsdfoundation.org/our-donors/donors/?donationYea...

    • Claro que seria bom se a Amazon contribuísse mais, mas não estar na lista de doadores da FreeBSD Foundation não significa que ela não apoie o FreeBSD
      Por exemplo, o dinheiro que me pagaram não passou pela Foundation. Eu estimaria que, do desenvolvimento de FreeBSD financiado por empresas, talvez uns 10% seja desenvolvimento apoiado pela Foundation
      Esses 10% são importantes porque podem se concentrar no que “o FreeBSD precisa”, e não especificamente no que “a empresa X precisa”, mas ainda assim são uma parcela pequena
    • Isso não mostra o quadro completo
      Primeiro, mostra apenas um instantâneo das doações à Foundation em um ano específico, então obviamente não revela o histórico de doações
      Segundo, também não mostra contribuições de desenvolvimento. Esse tipo de informação normalmente pode ser visto resumido nas notas de cada release [1]
      [1] https://www.freebsd.org/releases/
    • Fico curioso por que a Microsoft patrocina. As extensões Hyper-V não são tão completas quanto no Linux, e também não há um port do .NET suportado pela Microsoft
      Não me vem à cabeça nenhum serviço da Microsoft, na nuvem ou fora dela, rodando em *BSD
    • A Amazon é uma das FAANG que menos faz por software livre e de código aberto

  • Eu queria usar FreeBSD como gateway/firewall/DNS/servidor DHCP em casa, mas parecia não haver driver para minha NIC 10GbE, então acabei escolhendo Nix
    Usei FreeBSD como workstation há muito tempo, e foi uma experiência bastante marcante. É bom ver que ele ainda segue firme

    • Minha empresa e minha infraestrutura pessoal usam FreeBSD. No FreeBSD, NICs Intel são 100% confiáveis, então uso só elas
      Realtek parece quebrar sob carga, apesar dos esforços dos engenheiros do FreeBSD que mantêm o driver. Não estou reclamando; respeito o trabalho deles
      Esse é um preço pequeno a pagar, e evita que eu precise instalar um sistema operacional menos estável

  • Por volta do FreeBSD 7 ou 8, lembro de uma época em que, em coisas como placas Wi‑Fi Atheros, os drivers do FreeBSD eram melhores que os do Linux
    Eu preferia o FreeBSD até mais ou menos 2021, mas isso mudou quando computadores com diferentes tipos de núcleos de CPU misturados ficaram comuns. Primeiro comprei um RockPro64 com 2 núcleos big e 4 núcleos little; depois comprei um Intel Alder Lake
    Pelo que entendo, o escalonador do FreeBSD ainda não lida direito com essa configuração, então parece levar o sistema para o menor denominador comum, baseado nos núcleos mais lentos

  • Por curiosidade, quem são os principais usuários do FreeBSD/EC2?

    • Não faço a menor ideia. Falando sério, os usuários que entram em contato comigo provavelmente representam cerca de 0,1% da base total de usuários de FreeBSD/EC2
      Eu realmente gostaria de saber quem usa FreeBSD no EC2
    • A Netflix usa só em equipamentos de edge?

  • É um texto que mostra muito bem como funciona o patrocínio corporativo de open source

  • Alguém que usa FreeBSD poderia explicar qual nicho o FreeBSD ocupa no espaço Unix? Por que FreeBSD, e não o OpenBSD ou NetBSD, que são mais simples e consistentes?
    Se a resposta for suporte a ZFS, drivers da Nvidia, ELF e afins, então por que não Linux? Conheço bem os problemas do GNU, mas há problemas até em algo como Musl Void?
    É uma curiosidade genuína. Para mim, o FreeBSD existe como uma espécie de zona de sombra; nunca consegui identificar exatamente a identidade central que o mantém em movimento, mas sei que ela existe em algum lugar

    • Trabalhei em uma empresa de serviços financeiros que usava FreeBSD tanto no EC2 quanto em bare metal em datacenters gerenciados internamente. Os dois recursos que usávamos o tempo todo eram ZFS e jails
      Cada serviço rodava em sua própria jail para isolamento, e um único servidor nem tão potente conseguia executar todos os serviços, então a eficiência de custo era enorme
      Em certo momento fizemos uma migração para a nuvem para uma configuração híbrida e, ao misturar Linux (k8s) com FreeBSD, os custos dispararam. No datacenter, há as desvantagens de comprar e substituir discos diretamente, lidar com situações como incêndios e estar em apenas um país, mas a AWS oferece múltiplas regiões e vários recursos bons, e isso tem seu preço
      Não explorávamos ZFS de forma muito avançada, mas uma vez ele nos salvou bastante quando uma tabela foi apagada por engano no banco de dados de produção: fizemos rollback imediato para o snapshot ZFS anterior. Houve alguma perda de dados, mas, para aquela aplicação, o tempo de atividade era mais importante, então não foi um grande problema. Lembro que também usávamos ZFS para backups
      Usei dtrace algumas vezes para resolver problemas em produção e, quando introduzimos Linux no conjunto de servidores FreeBSD, cada equipe naturalmente escolheu uma distribuição diferente, virando uma espécie de zoológico. Ao usar FreeBSD em servidores, há apenas uma variante
      Ainda uso e gosto dos dois, mas gosto muito do fato de o FreeBSD ser uma forma integrada de kernel e sistema operacional
    • Na minha experiência, o FreeBSD oferece um bom equilíbrio entre os elementos que OpenBSD e NetBSD valorizam, respectivamente
      Historicamente, o FreeBSD priorizou CPUs Intel, o NetBSD tinha mais foco em portabilidade e, embora o FreeBSD também tivesse segurança sólida, o OpenBSD era mais focado em segurança
      O suporte a ZFS do FreeBSD é realmente algo capaz de mudar o jogo. Pelo que sei, a Nvidia só passou recentemente a oferecer drivers nativos para FreeBSD; por muito tempo foi necessário usar a funcionalidade de compatibilidade com o kernel Linux do FreeBSD
      Em outras palavras, o FreeBSD combinava bem os recursos oferecidos pelos outros BSDs e, ao mesmo tempo, era extremamente estável nas plataformas de hardware que eu mais usava
    • O FreeBSD é orientado a throughput de uma forma que o OpenBSD definitivamente não é, e acho que o NetBSD também não
      Tenho a impressão de que o NetBSD compete em portabilidade e não passa tanto tempo mantendo alto o throughput de rede
      Todos os BSDs, em geral, mudam muito menos e, embora isso tenha prós e contras, acho que são melhores como plataformas-alvo de integração
    • O FreeBSD tem suporte a ZFS melhor que o Linux porque não há problemas de licença
    • O FreeBSD tem uma base de usuários muito maior que OpenBSD ou NetBSD. Nem dá para comparar
      A lista de softwares também é muito maior, e ele pode ser usado como sistema operacional moderno de desktop no dia a dia. É difícil dizer isso dos outros dois
      Quanto a por que não Linux: eu não quero Linux. Ele é sufocado demais por interesses corporativos