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.