Hace pocos días compartimos aquí en el blog la noticia sobre la discusión que se estaba realizando de manera interna entre los desarrolladores de Fedora, en la cual comentaban acerca del cambio del editor vi por nano.
Y es que el implementar el uso predeterminado de nano en lugar de vi se debe al deseo de hacer que la distribución sea más accesible para los principiantes al proporcionar un editor que pueda ser utilizado por cualquier usuario que no tenga un conocimiento especial de los métodos de trabajo en el editor Vi.
Al mismo tiempo, se planea continuar con la entrega del paquete vim-minimal en el paquete de distribución básico (la llamada directa a vi permanecerá) y proporcionar la capacidad de cambiar el editor predeterminado a vi o vim a solicitud del usuario. Fedora actualmente no establece la variable de entorno $ EDITOR, y por defecto en comandos como «git commit» se llama vi.
Y bueno después de mucha plática, los desarrolladores aceptaron el cambio y este se aplicará para la siguiente version de Fedora, que es la version 33.
Además de esto, también se discutía por otra parte el cambio de EXT4 por Btrfs en la cual el Comité Directivo de Ingeniería de Fedora (FESCo), que es responsable del desarrollo técnico de la distribución de Fedora, aprobó una propuesta para usar el sistema de archivos Btrfs predeterminado en las ediciones de escritorio y portátiles de Fedora.
Además de que este comité también aprobó cambiar la distribución para usar el editor de nano texto predeterminado en lugar de vi.
Con estas decisiones tomadas a partir de Fedora 33 se cambiará del sistema de archivos Ext4 a Btrfs de forma predeterminada. Esta no es una revolución importante o un paso irreversible, sino solo un cambio en la configuración predeterminada de instalación del sistema, que en principio no afectará a las personas que actualicen desde Fedora anterior o aquellos que no quieran Btrfs. Ya que simplemente se quedan con su sistema de archivos preferido.
El razonamiento del cambio a Btrfs, es que este agregará nuevas capacidades y también abordará mejor las situaciones de ahorro de espacio no estándar para los usuarios.
Btrfs tiene algunas características que son útiles hoy en día, como instantáneas de copia en escritura, compresión transparente de datos a nivel del sistema de archivos, optimización para SSD, soporte nativo de RAID, ya indica una mejor gestión del espacio, un sistema de suma de comprobación más sofisticado, I/O aislamiento mediante cgroups2, soporte para la reducción y simplificación de particiones en línea y configuración de campo más fácil.
El uso del administrador de particiones Btrfs incorporado resolverá los problemas de quedarse sin espacio libre en el disco al montar los directorios / y /home por separado.
Además de que argumentan que otra gran ventaja es la capacidad de cambiar el tamaño de las particiones en línea, incluida la reducción, incluso en términos de posible integración systemd-homed.
Finalmente, Btrfs simplifica la administración y operación de sistemas de almacenamiento complejos y agrega replicación eficiente, copias de seguridad incrementales con Btrfs send/Btrfs receive etc.
En cuanto a otros de los cambios que aun esta sobre la mesa y que aun se discutiendo, es el tema de discontinuar el soporte para el arranque usando el BIOS clásico y dejar la opción de instalar solo en sistemas que admiten UEFI.
Esto, se puso sobre la mesa, ya que se observa que los sistemas basados en la plataforma Intel se han enviado desde UEFI desde 2005, y para 2020 Intel planeaba dejar de admitir BIOS en sistemas cliente y plataformas de centros de datos.
La discusión sobre el rechazo del soporte de BIOS en Fedora también se debe a la simplificación de la implementación de la tecnología de visualización selectiva del menú de arranque, en el que el menú está oculto por defecto y se muestra solo después de un fallo o activación de la opción en GNOME.
Para UEFI, la funcionalidad necesaria ya está disponible en sd-boot, pero cuando se usa el BIOS requiere parches para GRUB2.
Fuente: desdelinux
