Um ano de patrocínio para o desenvolvimento do FreeBSD
(daemonology.net)- Com patrocínio da Amazon, foi realizado por um ano o trabalho de engenharia de release do FreeBSD e desenvolvimento de FreeBSD/EC2
- Gestão de releases e melhorias relacionadas ao EC2 foram conduzidas em paralelo, com média de 50 horas de trabalho por mês
- Foram resolvidos problemas importantes de funcionalidade e qualidade, incluindo gerenciamento de energia em instâncias Graviton, suporte a hotplug e melhorias no desempenho de boot
- A expansão dos tipos de AMI e a automação de builds aumentaram a variedade e a eficiência da distribuição de AMIs do FreeBSD
- Após o fim do patrocínio, é esperado um ritmo menor de desenvolvimento e estagnação em parte da evolução de recursos
Retrospectiva de um ano de patrocínio ao desenvolvimento do FreeBSD
# Contexto inicial e processo de patrocínio
- O autor administra a plataforma FreeBSD/EC2 desde 2010 e, desde novembro de 2023, também exerce o papel de líder de engenharia de release do FreeBSD
- Havia pequenos apoios via Antithesis, Patreon e outros, mas o trabalho de engenharia de release passou a consumir grande parte do tempo antes dedicado ao desenvolvimento de FreeBSD/EC2
- Após anos de conversas com a Amazon sobre patrocínio para o trabalho no EC2, em abril de 2024 houve contato com a pessoa responsável pelo orçamento e o apoio de um ano foi viabilizado
- O patrocínio foi executado por meio do GitHub Sponsors, e o período pretendido pela Amazon pode não coincidir exatamente com a data real dos repasses
# Patrocínio e distribuição do tempo de trabalho
- A pedido da Amazon, foi assumido o compromisso de fornecer 40 horas mensais de trabalho em engenharia de release do FreeBSD e desenvolvimento para EC2
- Na prática, foram investidas cerca de 50 horas por mês, distribuídas em 20 horas para questões de EC2, 20 horas para releases e 10 horas para outras atividades de engenharia
- O número de horas variou bastante de um mês para outro
# Gestão de releases do FreeBSD
- Ao introduzir e administrar um cronograma trimestral de releases do FreeBSD, foram realizados quatro releases em um ano: FreeBSD 13.4 (2024.9), 14.2 (2024.12), 13.5 (2025.3), 14.3 (previsão para 2025.6)
- Cada release incluiu incentivo ao congelamento de código pelos desenvolvedores, aprovação e coordenação de pedidos de merge, build e testes de imagens, redação de comunicados e correção de vários erros nos builds de release
- O tempo gasto com engenharia de release ficou entre 33,5 e 79 horas por trimestre, com tendência de redução da carga de trabalho na parte final devido à estabilização
# Principais melhorias de recursos do EC2 e de qualidade
Driver de energia para instâncias Graviton e suporte a hotplug
-
Foi resolvido o problema em que o FreeBSD não reconhecia o sinal de desligamento normal da API do EC2 em instâncias Graviton
- Foi usado o objeto ACPI _AEI para ligar o sinal de "power button" baseado em GPIO à lógica do driver
- O problema de desativação de dispositivo causado por inconsistência na configuração da flag Pull Up nas tabelas ACPI fornecidas pelo EC2 foi tratado com a adição da configuração ACPI_Q_AEI_NOPULL na AMI FreeBSD/EC2
-
Problemas de hotplug de dispositivos (especialmente hot-unplug) em instâncias EC2 Graviton e x86 foram diagnosticados e corrigidos de forma abrangente
- Foram tratados vários tipos de bugs, como vazamento de IRQ, inconsistência entre estado de energia PCI e sinalização do sistema operacional, e dispositivos PCI “fantasma”
- Como medida temporária, foram aplicados quirks de ACPI (por exemplo, ACPI_Q_CLEAR_PME_ON_DETACH e ACPI_Q_DELAY_BEFORE_EJECT_RESCAN), enquanto bugs do lado do EC2 ainda devem ser corrigidos
Automação de testes de hotplug e melhoria de qualidade
- Foi desenvolvido um script para conectar e desconectar repetidamente volumes EBS no ambiente EC2, validando a estabilidade com 300 testes consecutivos
- Atrasos desnecessários de 5 segundos no hotplug PCIe, que só fazem sentido em sistemas físicos, foram ajustados para 0 segundo no EC2, melhorando a qualidade
Melhorias no desempenho de boot
- Problemas de velocidade de boot do FreeBSD/EC2 foram melhorados de forma sistemática com coleta e análise de dados
- No início de 2024, foram resolvidos em sequência problemas como triplicação do tempo de boot após aumento do tamanho do disco raiz, atraso no seed de entropia do kernel em instâncias Graviton2, aumento do tempo de boot com ZFS e questões de suporte a IPv6 relacionadas ao IMDSv2
- Houve otimizações em várias frentes, incluindo diferenças de desempenho de boot por sistema de arquivos, ineficiência no fornecimento de entropia e atraso na inicialização de rede
# Expansão da variedade de AMIs do FreeBSD e automação de build/distribuição
- Além das AMIs existentes base e cloud-init, foram adicionadas a small AMI (remoção de código e ferramentas desnecessários de depuração/teste, tamanho de 1 GB) e a builder AMI (builder para personalização pelo usuário)
- Com a ampliação das combinações de imagem para 4 tipos de AMI * 2 sistemas de arquivos (UFS/ZFS) * 2 arquiteturas (amd64/arm64) * 3 versões (13, 14, 15), avançaram a remoção automática de imagens antigas e a criação de scripts, incluindo a limpeza de 336 TB de snapshots EBS
# Melhorias gerais de engenharia
- A paralelização dos builds de AMI/release do FreeBSD reduziu o tempo total de build de cerca de 22 horas para 13 horas, abrindo margem para adicionar mais tipos de AMI
- Com testes automatizados baseados em instâncias EC2 e comparação via diffoscope, avançaram o diagnóstico e a correção de problemas de reprodutibilidade de build (reproducible builds)
- Também foram conduzidas várias tarefas menores, como revisão de patches do driver ENA, build de contêineres OCI e upload para registry, melhorias em ferramentas relacionadas à AWS e relatórios de problemas de segurança
# Perspectivas e limitações daqui para frente
- O papel de manter a engenharia de release do FreeBSD e a plataforma EC2 continuará, mas a expectativa é de menos tempo disponível do que antes
- Os releases FreeBSD 15.0 (2024.12) e 14.4/15.1/14.5/15.2 (2026) devem seguir conforme planejado, mas a velocidade de adição de recursos e correção de bugs tende a cair
- Tarefas ainda inacabadas, como expansão automática do sistema de arquivos, múltiplas NICs e automação de hotplug, distribuição de AMIs com patches pré-aplicados, ferramenta web para usuários de EC2 e suporte a FreeBSD/Firecracker, devem permanecer estagnadas no longo prazo
# Encerramento
- Esse patrocínio da Amazon foi uma oportunidade extremamente rara para um desenvolvedor de código aberto, e há orgulho e gratidão pelos resultados alcançados até aqui
1 comentários
Comentários do Hacker News
Hoje compartilharam a notícia de que o FreeBSD foi adicionado à página de downloads do ziglang.org, então agora usuários de FreeBSD podem obter facilmente builds do branch master geradas automaticamente na CI
O FreeBSD agora também é oficialmente totalmente suportado como alvo de cross-compilation, então dá para compilar mirando FreeBSD de forma parecida com Linux, como em
zig cc -o hello hello.c -target riscv64-freebsdSe houver dependências em C/C++, elas podem ser trazidas e compiladas facilmente com o sistema de build do Zig, o que permite até fazer cross-compilation para FreeBSD de projetos bem complexos com facilidade
Tomara que isso leve mais projetos a adicionarem suporte e testes para FreeBSD na CI
Houve várias partes divertidas de ler
Um caso em que, desde a primeira semana de 2024, o processo de boot do FreeBSD de repente ficou 3 vezes mais lento; depois de rastrear commits continuamente, descobriram que a causa era o aumento do tamanho do disco raiz de 5 GB para 6 GB
Ao perguntar a um contato da Amazon, a resposta pareceu quase magia: “não sei exatamente o motivo, mas talvez seja melhor não saber”
O importante é que, ao aumentar o tamanho do disco raiz para 8 GB, o desempenho voltou ao nível anterior
Ao ouvir uma história dessas, bate mesmo a vontade de entender por que isso acontece
Fica a curiosidade sobre quanto tempo de fato levou para fazer bisect de commits para encontrar esse problema
Imaginando se foi preciso gerar uma imagem e reiniciar a VM toda vez
Menção a um post do próprio autor no blog em 2006 dizendo que o limite original de tamanho de objeto do S3 era 5 GB
https://aws.amazon.com/blogs/aws/amazon_s3/
Não sabe se isso tem relação direta com a lentidão observada no FreeBSD
Também há muito trabalho em andamento em suporte a notebooks
Leitura de que a BSD Foundation está investindo $750,000 para focar em vários recursos, incluindo a implementação do estado de suspensão S0ix
Os projetos relacionados podem ser vistos em https://github.com/FreeBSDFoundation/proj-laptop
Esperava-se que a Amazon desse mais apoio e contribuísse mais, mas na prática parece ficar no suporte mínimo ao FreeBSD
A Amazon nem aparece na lista de patrocinadores do FreeBSD, o Google doou só $9K no ano passado, e Apple e Meta/Facebook também não aparecem
Em contraste, vale elogiar a Microsoft por estar na lista
Surpreende que essas big techs se beneficiem tanto de FreeBSD e OpenBSD e não façam doações automáticas todo ano
As informações de patrocínio podem ser vistas em https://freebsdfoundation.org/our-donors/donors/?donationYear=2024
Concordo com a ideia de que a Amazon deveria apoiar mais o FreeBSD
Mas o fato de ela não aparecer na lista de doadores da FreeBSD Foundation não significa que não haja apoio
O financiamento de desenvolvimento que ele recebeu também não passou pela fundação, e na prática o desenvolvimento apoiado pela fundação representa só cerca de 10% do apoio corporativo total
O desenvolvimento financiado pela fundação é importante porque permite focar em trabalho para o próprio FreeBSD, mas no total ainda é minoria
Observação de que não dá para enxergar o quadro completo só por esse comentário
Ele mostra apenas um retrato das doações feitas à fundação por ano, enquanto o desenvolvimento contribuído em si está resumido nas notas de release de cada versão
https://www.freebsd.org/releases/
Curiosidade sobre por que a Microsoft apoia o FreeBSD
As extensões para Hyper-V nem são tão completas quanto no Linux, não há port oficial do .NET, e também não parece que a Microsoft opere serviços baseados em FreeBSD
Opinião de que a Amazon é a empresa da FAANG que menos contribui para FOSS
Muito respeito ao cperciva
Fica a curiosidade de como ele consegue tocar Tarsnap e FreeBSD ao mesmo tempo
Consertos simples podem ser feitos por conta própria ou delegados a um profissional
Só parte do tempo investido nesse trabalho com FreeBSD veio do tempo liberado por Tarsnap, e não foi tanto quanto se imagina
Já houve experiência anterior usando FreeBSD como workstation, e a impressão foi boa
Havia vontade de usar FreeBSD como gateway/firewall/DNS/DHCP de casa, mas como a placa de rede 10GbE não era suportada, acabou escolhendo Nix
É bom ver que o FreeBSD continua bem mantido
Curiosidade sobre quem são os maiores usuários de FreeBSD/EC2
Ele também não sabe bem
Na prática, os usuários que entram em contato com ele provavelmente não representam nem 0,1% de todos os usuários de FreeBSD/EC2
Ele gostaria muito de saber quem usa FreeBSD no EC2
Curiosidade se a Netflix usa FreeBSD só em edge boxes
Curiosidade sobre que nicho o FreeBSD ocupa dentro do mundo Unix
Pergunta de por que usar o FreeBSD, mais complexo, em vez de OpenBSD ou NetBSD, e se para precisar de ZFS, Nvidia ou ELF não seria melhor simplesmente usar Linux
Os problemas com GNU são conhecidos, mas existem alternativas como Musl Void, então a curiosidade sincera é qual seria a “identidade” própria do FreeBSD
Experiência no setor financeiro usando FreeBSD tanto no EC2 quanto em servidores bare metal no próprio datacenter
Uso intenso de zfs e jails
Todos os serviços rodavam de forma isolada em cada jail, com ótima eficiência de custo
Quando parte disso foi migrada para a nuvem e passou a operar em modo híbrido com Linux(k8s)+FreeBSD, os custos dispararam
Gerenciar diretamente o datacenter tem inconvenientes, como trocar discos ou lidar com incêndios, mas a AWS oferece vários recursos como multirregião (com custo alto)
zfs já ajudou muito quando uma tabela de banco de dados de produção foi apagada por engano, permitindo rollback imediato graças a snapshots; zfs também era usado para backup
Também houve experiência de troubleshooting em produção com dtrace
Quando só havia FreeBSD nos servidores, era fácil administrar por haver uma única família de SO; ao introduzir Linux, cada time passou a usar uma distribuição diferente, gerando confusão
Apreço pelo FreeBSD como uma estrutura integrada de kernel + sistema operacional
Na visão dele, o FreeBSD parece uma boa mistura dos pontos fortes do OpenBSD e do NetBSD
No passado, o FreeBSD se destacava por otimização para CPUs Intel e segurança sólida, e especialmente o suporte a ZFS era o grande diferencial
O driver da Nvidia também só recentemente ganhou suporte nativo ao FreeBSD
No fim, o FreeBSD combina bem os pontos fortes dos outros BSDs com estabilidade de hardware
O FreeBSD tem uma base de usuários muito maior do que OpenBSD ou NetBSD
O catálogo de software em si também é muito mais amplo, então dá para usar tranquilamente até no dia a dia em desktop
E quanto a não usar Linux, é porque Linux está amarrado demais aos interesses corporativos
Opinião de que o FreeBSD está um passo à frente do Linux em suporte a ZFS
Por causa de questões de licença, o FreeBSD oferece um ambiente melhor
O FreeBSD supera o OpenBSD em termos de throughput de rede
De modo geral, os BSDs mudam menos, o que os torna bons como plataforma integrada
Opinião de que este texto não pinta um quadro muito bom do ambiente de desenvolvimento do FreeBSD
Considerando que é um sistema operacional de grande complexidade, parece uma pena que, no mínimo, não haja alguém em tempo integral como gerente de release, e que no fim tenha sido apenas meio período por um ano
Ainda assim, a existência do FreeBSD é importante por mostrar que Linux não é a única alternativa