Un año de patrocinio para el desarrollo de FreeBSD
(daemonology.net)- Con el patrocinio de Amazon, se trabajó durante un año en ingeniería de lanzamientos de FreeBSD y en el desarrollo de FreeBSD/EC2
- Se combinaron la gestión de lanzamientos y las mejoras relacionadas con EC2, con un promedio de 50 horas de trabajo al mes
- Se resolvieron problemas clave de funcionalidad y se mejoró la calidad en aspectos como gestión de energía en instancias Graviton, soporte de hotplug y mejoras en el rendimiento de arranque
- La ampliación de tipos de AMI y la automatización de builds aumentaron la diversidad y eficiencia del despliegue de FreeBSD AMI
- Tras el fin del patrocinio, se espera una desaceleración en el ritmo de desarrollo y estancamiento en algunas funciones
Balance de un año de patrocinio para el desarrollo de FreeBSD
# Contexto inicial y proceso de patrocinio
- Ha mantenido la plataforma FreeBSD/EC2 desde 2010, y desde noviembre de 2023 también asumió el rol de líder de ingeniería de lanzamientos de FreeBSD
- Recibía pequeños patrocinios de Antithesis, Patreon y otros, pero el trabajo de ingeniería de lanzamientos estaba consumiendo gran parte del tiempo destinado al desarrollo de FreeBSD/EC2
- Durante varios años mantuvo conversaciones con Amazon sobre un patrocinio para el trabajo en EC2, y en abril de 2024 fue conectado con la persona encargada del presupuesto, lo que permitió obtener apoyo por un año
- El patrocinio se canalizó a través de GitHub Sponsors, y el período previsto por Amazon puede no coincidir con la fecha real de los depósitos
# Patrocinio y distribución del tiempo de trabajo
- A pedido de Amazon, se comprometió a dedicar 40 horas mensuales a ingeniería de lanzamientos de FreeBSD y desarrollo para EC2
- En la práctica dedicó alrededor de 50 horas por mes, distribuidas en 20 horas para problemas de EC2, 20 horas para lanzamientos y 10 horas para otras tareas de ingeniería
- La cantidad de horas trabajadas varió considerablemente de un mes a otro
# Gestión de lanzamientos de FreeBSD
- Al introducir y administrar un calendario trimestral de lanzamientos de FreeBSD, llevó a cabo cuatro lanzamientos en un año: FreeBSD 13.4 (2024.9), 14.2 (2024.12), 13.5 (2025.3), 14.3 (previsto para 2025.6)
- Cada lanzamiento incluyó incentivar el cierre de código por parte de los desarrolladores, aprobar y coordinar solicitudes de merge, construir y probar imágenes, redactar avisos y corregir diversos errores de build del lanzamiento
- El tiempo requerido para ingeniería de lanzamientos fue de entre 33.5 y 79 horas por trimestre, con una tendencia a disminuir hacia el final gracias a la estabilización del proceso
# Principales mejoras de funciones de EC2 y aumento de calidad
Driver de energía para instancias Graviton y soporte de hotplug
-
Se resolvió el problema por el cual FreeBSD no detectaba la señal de apagado correcto de la API de EC2 en instancias Graviton
- Se usó el objeto ACPI _AEI para conectar la señal de "power button" basada en GPIO con la lógica del driver
- El problema de desactivación del dispositivo causado por una discrepancia en la configuración de la bandera Pull Up en las tablas ACPI proporcionadas por EC2 se abordó añadiendo la configuración ACPI_Q_AEI_NOPULL a las AMI de FreeBSD/EC2
-
Se diagnosticaron y corrigieron de forma integral problemas de hotplug de dispositivos (especialmente hot unplug) en instancias EC2 Graviton y x86
- Se atendieron distintos tipos de bugs, incluidos fugas de IRQ, desajustes entre el estado de energía de PCI y las señales del SO, y dispositivos PCI "fantasma"
- Como solución temporal, se aplicaron quirks de ACPI (por ejemplo, ACPI_Q_CLEAR_PME_ON_DETACH y ACPI_Q_DELAY_BEFORE_EJECT_RESCAN), mientras que los bugs del lado de EC2 quedan pendientes de corrección
Automatización de pruebas de hotplug y mejora de calidad
- Se desarrolló un script para conectar y desconectar repetidamente volúmenes EBS en el entorno EC2, validando la estabilidad mediante 300 pruebas consecutivas
- Se mejoró la calidad al configurar en 0 segundos la demora innecesaria de 5 segundos del hotplug PCIe en EC2, ya que solo tiene sentido en sistemas físicos
Mejora del rendimiento de arranque
- Los problemas de velocidad de arranque de FreeBSD/EC2 se mejoraron de manera sistemática mediante recopilación y análisis de datos
- Se resolvieron de forma gradual problemas como la triplicación del tiempo de arranque tras ampliar la capacidad del disco raíz a inicios de 2024, demoras en el sembrado de entropía del kernel en instancias Graviton2, aumento del tiempo de arranque con ZFS y problemas de soporte IPv6 relacionados con IMDSv2
- Se lograron optimizaciones en múltiples frentes, como las diferencias de rendimiento de arranque según el sistema de archivos, la ineficiencia en la obtención de entropía y las demoras en la inicialización de red
# Ampliación de la variedad de FreeBSD AMI y automatización de build/despliegue
- Además de las AMI existentes base y cloud-init, se añadieron small AMI (sin código/herramientas innecesarias de depuración y prueba, tamaño de 1 GB) y builder AMI (builder personalizable por el usuario)
- Con la expansión de combinaciones de imágenes a 4 tipos de AMI * 2 sistemas de archivos (UFS/ZFS) * 2 arquitecturas (amd64/arm64) * 3 versiones (13, 14, 15), se avanzó en la eliminación automática de imágenes antiguas y en la creación de scripts, limpiando 336 TB de snapshots EBS
# Mejoras generales de ingeniería
- La paralelización de los builds de FreeBSD AMI/lanzamientos redujo el tiempo total de build de unas 22 horas a 13 horas, dejando margen para añadir más tipos de AMI
- Se avanzó en el diagnóstico y resolución de problemas de reproducibilidad de builds (reproducible builds) mediante pruebas automatizadas basadas en instancias EC2 y comparaciones con diffoscope
- También se realizaron diversas tareas pequeñas, como revisión de parches del driver ENA, builds de contenedores OCI y subida al registro, mejoras en herramientas relacionadas con AWS y reportes de problemas de seguridad
# Perspectivas y limitaciones a futuro
- Se mantendrán las funciones de ingeniería de lanzamientos de FreeBSD y mantenimiento de la plataforma EC2, pero se prevé que el tiempo disponible sea menor que antes
- Los lanzamientos de FreeBSD 15.0 (2024.12) y 14.4/15.1/14.5/15.2 (2026) seguirán según lo previsto, aunque probablemente disminuya la velocidad de incorporación de funciones y corrección de bugs
- Tareas pendientes como la expansión automática del sistema de archivos, automatización para múltiples NIC y hotplug, distribución de AMI preparchadas, herramientas web para usuarios de EC2 y soporte para FreeBSD/Firecracker probablemente queden estancadas a largo plazo
# Cierre
- Este patrocinio de Amazon fue una oportunidad extremadamente rara para un desarrollador de código abierto, y expresa orgullo y gratitud por los logros obtenidos hasta ahora
1 comentarios
Comentarios en Hacker News
Hoy compartieron la noticia de que se agregó FreeBSD a la página de descargas de ziglang.org, así que ahora los usuarios de FreeBSD pueden obtener fácilmente builds de la rama master generadas automáticamente en CI
FreeBSD ahora también está totalmente soportado oficialmente como objetivo de compilación cruzada, y ya se puede compilar apuntando a FreeBSD de forma similar a Linux, por ejemplo
zig cc -o hello hello.c -target riscv64-freebsdSi hay dependencias de C/C++, se pueden incorporar y compilar fácilmente con el sistema de build de Zig, así que incluso proyectos bastante complejos se pueden compilar cruzadamente para FreeBSD sin mucho problema
Ojalá esto haga que más proyectos agreguen soporte y pruebas para FreeBSD en su CI
Hubo muchas partes divertidas de leer
Un caso donde, desde la primera semana de 2024, el proceso de arranque de FreeBSD de repente se volvió 3 veces más lento; tras seguir los commits una y otra vez, la causa terminó siendo que el tamaño del disco raíz había pasado de 5 GB a 6 GB
Le preguntaron a un amigo de Amazon y la respuesta sonó casi como magia: “no sé exactamente por qué, pero quizá es mejor no saberlo”
Lo importante es que al aumentar el disco raíz a 8 GB, el rendimiento volvió a su nivel anterior
Escuchar algo así hace que ahora de verdad quiera saber por qué pasa
Me pregunto cuánto tiempo habrá tomado hacer bisección de commits para encontrar un problema así
Me imagino reiniciando la VM y recreando la imagen cada vez
Mención de una entrada de su propio blog de 2006 sobre que el límite original de tamaño de objetos en S3 era de 5 GB
https://aws.amazon.com/blogs/aws/amazon_s3/
No sabe si eso está directamente relacionado con la lentitud de rendimiento en FreeBSD
También están avanzando muchas cosas en soporte para laptops
Leyó que la BSD Foundation está invirtiendo $750,000 para enfocarse en varias funciones, incluida la implementación de S0ix Sleep State
Se pueden ver proyectos relacionados en https://github.com/FreeBSDFoundation/proj-laptop
Esperaba que Amazon diera más soporte y contribuyera más, pero la realidad parece quedarse en el soporte mínimo para FreeBSD
Amazon ni siquiera aparece en la lista de patrocinadores de FreeBSD, Google el año pasado solo donó $9K, y tampoco están Apple ni Meta/Facebook
En cambio, sí hay que reconocerle a Microsoft que aparece en la lista
Sorprende que estas grandes empresas se beneficien tanto de FreeBSD y OpenBSD y no donen automáticamente cada año
La información de patrocinadores se puede ver en https://freebsdfoundation.org/our-donors/donors/?donationYear=2024
Coincido en que ojalá Amazon apoyara más a FreeBSD
Pero que no aparezca en la lista de donantes de la FreeBSD Foundation no significa que no haya apoyo
El financiamiento de desarrollo que recibió él tampoco pasó por la fundación, y en realidad el desarrollo que apoya la fundación representa solo como un 10% de todo el apoyo corporativo
El trabajo financiado por la fundación es importante porque permite enfocarse en cosas para FreeBSD en sí, pero en el panorama general sigue siendo una minoría
Señalan que con solo este comentario no se puede ver toda la situación
Solo muestra una foto de lo donado a la fundación por año, mientras que el desarrollo aportado en sí está resumido en las notas de lanzamiento de cada versión
https://www.freebsd.org/releases/
Curiosidad por saber por qué Microsoft apoya a FreeBSD
Las extensiones de Hyper-V ni siquiera están tan completas como en Linux, no hay un port oficial de .NET, y tampoco parece que Microsoft opere servicios basados en FreeBSD
Opinión de que Amazon es la empresa de FAANG que menos contribuye al FOSS
Mucho respeto para cperciva
Me pregunto cómo logra llevar Tarsnap y FreeBSD al mismo tiempo
Uno puede hacer reparaciones simples por su cuenta o llamar a un experto
Solo una parte del tiempo dedicado a este trabajo de FreeBSD salió del tiempo tomado de Tarsnap, y no fue tanto como podría parecer
Antes probó usar FreeBSD como workstation, y le impresionó
Quiso usar FreeBSD como gateway/firewall/DNS/DHCP en casa, pero como no tenía soporte para el driver de su NIC de 10GbE, al final eligió Nix
Da gusto ver que FreeBSD sigue bien mantenido
Me pregunto quiénes son los principales usuarios de FreeBSD/EC2
Él tampoco lo sabe bien
Parece que los usuarios que realmente lo contactan ni siquiera representan el 0.1% del total de usuarios de FreeBSD/EC2
De verdad le gustaría saber quién usa FreeBSD en EC2
Me pregunto si Netflix usa FreeBSD solo en cajas de borde
Curiosidad por saber qué nicho ocupa FreeBSD dentro de la familia Unix
Pregunta por qué usar FreeBSD, que es más complejo, en lugar de OpenBSD o NetBSD, y si para ZFS, Nvidia o ELF no sería mejor simplemente Linux
Conoce el problema de GNU, pero existen alternativas como Musl Void, así que siente curiosidad genuina por cuál sería la “identidad” clara de FreeBSD
Experiencia de uso de FreeBSD en finanzas tanto en EC2 como en servidores bare metal en su propio datacenter
Usaban mucho zfs y jails
Corrían todos los servicios aislados en cada jail y era muy eficiente en costos
Cuando migraron parte a la nube y operaron un esquema híbrido Linux(k8s)+FreeBSD, los costos se dispararon
Administrar directamente el datacenter tiene molestias como cambiar discos o responder a incendios, pero AWS ofrece varias funciones como multirregión, aunque con un costo alto
zfs ayudó muchísimo una vez que una tabla de base de datos de producción fue borrada por error, porque pudieron hacer rollback de inmediato gracias a snapshots, y también usaban zfs para backups
También tuvo experiencia haciendo troubleshooting en producción con dtrace
Cuando operaban solo FreeBSD en servidores, era fácil de gestionar porque solo había una familia de OS; al introducir Linux, cada equipo empezó a usar una distro distinta y hubo confusión
Le gusta FreeBSD como una estructura integrada de kernel + sistema operativo
Desde su punto de vista, FreeBSD se siente como una mezcla equilibrada de las ventajas de OpenBSD y NetBSD
En el pasado, FreeBSD presumía optimización para CPUs Intel y seguridad sólida, y en especial el soporte de ZFS era el diferenciador clave
El soporte nativo para drivers de nvidia en FreeBSD también llegó apenas hace poco
Al final, FreeBSD combina bastante bien las fortalezas de otros BSD con estabilidad de hardware
FreeBSD tiene una base de usuarios mucho más grande que OpenBSD o NetBSD
Su catálogo de software también es mucho más amplio, así que perfectamente puede usarse a diario en desktop
Y sobre por qué no usar Linux: porque Linux está demasiado atado a los intereses corporativos
Opinión de que FreeBSD está un nivel arriba de Linux en soporte de ZFS
Gracias al tema de licencias, FreeBSD ofrece un mejor entorno
FreeBSD supera a OpenBSD en rendimiento de networking
En general, los BSD cambian menos rápido, así que son buenos como plataforma integrada
Este texto deja la impresión de que el entorno de desarrollo de FreeBSD no está en muy buen estado
Considerando que es un OS de gran complejidad, uno pensaría que al menos alguien debería llevar el rol de release manager de tiempo completo, pero da lástima ver que todo se reduce a un año de trabajo de medio tiempo
Aun así, la existencia de FreeBSD importa porque Linux no es la única alternativa