Los desarrolladores de Fedora han dado a conocer una nueva propuesta para ser implementada en el próximo lanzamiento de Fedora 42 (programado para finales de abril), la cual introduce la posibilidad de que los mantenedores empaqueten variantes ejecutables adicionales optimizadas para las microarquitecturas x86-64-v2, x86-64-v3 y x86-64-v4.
Se menciona que la finalidad de esta propuesta, es el aprovechar las mejoras específicas en el rendimiento según las capacidades del hardware, aunque Fedora continuará produciendo paquetes para la arquitectura estándar x86-64-v1.
Cabe destacar que otras distribuciones ya están avanzando en esta dirección, ya que se menciona como ejemplo a CentOS, en donde se compila usando x86-64-v2, mientras que RHEL 10 se basa en x86-64-v3. Si bien las mejoras de rendimiento suelen rondar el 10%, ciertos escenarios muestran incrementos notables, llegando hasta un 120%.
En este modelo, las bibliotecas optimizadas se colocan en subdirectorios específicos, permitiendo al vinculador dinámico cargar automáticamente la versión más adecuada. Para archivos ejecutables, Fedora planea implementar un sistema similar mediante la capa hwcaps-loader, que seleccionará y ejecutará la variante más compatible con las capacidades de la CPU detectadas. Los mantenedores decidirán qué paquetes incluirán estas variantes adicionales, basándose en pruebas de rendimiento concretas.
Actualmente, la propuesta, aún pendiente de aprobación por el FESCo (Fedora Engineering Steering Committee) el cual tiene como objetivo ampliar el soporte existente para bibliotecas optimizadas, que actualmente se entregan utilizando el mecanismo de glibc-hwcaps.
Unificación de grub y shim en Fedora 42
Además de ello, otro de los cambios que se han propuesto para Fedora 42 es el de unificar los métodos de actualización de los gestores de arranque GRUB y Shim en las versiones estándar y atómicas de la distribución. Esta propuesta busca reemplazar el lugar donde los scripts de instalación de paquetes RPM actualizan directamente los directorios /boot y /boot/efi, con el uso del kit de herramientas bootupd, ya implementado en las versiones atómicas de Fedora.
La nueva propuesta plantea que los paquetes RPM que contienen gestores de arranque instalen sus componentes en un directorio separado dentro de la partición /usr, en lugar de modificar directamente los directorios mencionados. Posteriormente, el contenido de /usr se sincronizaría con /boot y /boot/efi mediante bootupd.
Se menciona que al implementar este cambio, se presentan varias ventajas significativas:
- Mayor seguridad y confiabilidad: El uso de bootupd permitiría implementar una opción de arranque alternativo. Esto significa que, en caso de problemas tras una actualización del gestor de arranque, los usuarios podrían revertir a una configuración anterior sin riesgos de dejar el sistema inoperable.
- Consistencia entre variantes: Al adoptar un enfoque común para las versiones atómicas y estándar de Fedora, se simplificaría el mantenimiento y se reducirían discrepancias entre los métodos de actualización.
- Modularidad: Al separar los componentes del gestor de arranque en /usr, se facilita la administración de los paquetes, reduciendo posibles conflictos durante las actualizaciones.
Fedora 42 dice adiós a SquashFS
Por último y no menos importante, también en Fedora 42 se tiene contemplado migrar todas las compilaciones activas de la distribución desde SquashFS hacia el sistema de archivos EROFS, esto con la finalidad de aprovechar las capacidades avanzadas de EROFS, que ya cuenta con soporte para Dracut desde su versión 103. Sin embargo, esta propuesta aún requiere la aprobación del FESCo (Fedora Engineering Steering Committee), encargado de las decisiones técnicas en el desarrollo de Fedora.
Se menciona que la elección de EROFS es por la necesidad de adoptar un sistema de archivos en constante desarrollo, ya que SquashFS no ha recibido actualizaciones significativas desde 2023. EROFS, por el contrario, sigue evolucionando e incorporando mejoras que podrían ofrecer beneficios a largo plazo para la distribución. Además, su método único para la compresión de datos, basado en bloques de tamaño fijo después de la compresión, lo diferencia de otros sistemas y permite un manejo más eficiente del rendimiento en ciertas situaciones.
El cambio afectará a todas las imágenes del sistema que operan en modo de solo lectura, como las ediciones Live con escritorios KDE, Xfce, Budgie, LXQt, MiracleWM y COSMIC. También incluirá variantes especializadas como Fedora KDE Plasma Mobile y Fedora CoreOS Live. La decisión busca aprovechar las ventajas que ofrece EROFS en términos de rendimiento y velocidad de acceso aleatorio.
Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...