En Fedora 33 se cambiará a Vi por Nano y se discute el descontinuar el soporte para BIOS
Los desarrolladores de Fedora no se han quedado con los brazos cruzados ante la actual problemática que se vive por la pandemia y es que han dado a conocer durante los últimos días varias noticias bastante interesantes en cuanto a lo que refiere para las futuras versiones de la distribución y en especial para Fedora 33.
Ya que dentro de los cambios que se tienen contemplados para Fedora 33, dieron a conocer que tienen planeado realizar un cambio el cual es de pasar de usar el editor de texto por defecto “Vi” a tomar la propuesta realizada por Chris Murphy del grupo de trabajo sobre el desarrollo de Fedora Workstation la cual consiste en implementar a Nano.
Esta propuesta no está aún aprobada del todo por el Comité, FESCO (Comité Directivo de Ingeniería de Fedora), responsable de la parte técnica del desarrollo de la distribución de Fedora.
Como motivo para usar el editor de texto nano como predeterminado en lugar de vi, se menciona el deseo de hacer que la distribución sea más accesible para los principiantes, proporcionando un editor que puede 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.
Además de que Fedora actualmente no establece la variable de entorno $ EDITOR, y por defecto en comandos como «git commit» se llama vi.
Otro de los cambios que dieron a conocer los desarrolladores de Fedora y que están discutiendo, es el tema de detener 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.
En la discusión, algunos desarrolladores no estuvieron de acuerdo con la interrupción del soporte de BIOS, ya que el costo de la optimización será la terminación de la posibilidad de usar nuevas versiones de Fedora en algunas computadoras portátiles y PC lanzadas antes de 2013 y entregadas con tarjetas gráficas sin vBIOS compatible con UEFI.
También menciona la necesidad de iniciar Fedora en sistemas de virtualización que solo admiten BIOS.
Por otra parte otros de los cambios discutidos para la implementación en Fedora 33 incluyen:
- Uso del sistema de archivos Btrfs predeterminado en las ediciones de escritorio y portátiles de Fedora. 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.
Con Btrfs, estas particiones se pueden colocar en dos subsecciones, montadas por separado, pero utilizando el mismo espacio en disco.
Btrfs también le permitirá usar características como instantáneas, compresión de datos transparente, aislamiento correcto de las operaciones de entrada / salida a través de cgroups2, redimensionando particiones sobre la marcha. - Se planea agregar un proceso SID en segundo plano (Storage Instantiation Daemon) para rastrear el estado de los dispositivos en varios subsistemas de almacenamiento (LVM, multipath, MD) y controladores de llamadas cuando ocurren ciertos eventos, por ejemplo, para activar y desactivar dispositivos. SID funciona como un complemento en udev y responde a los eventos de este, eliminando la necesidad de crear reglas udev complicadas para interactuar con varias clases de dispositivos y subsistemas de almacenamiento que son difíciles de mantener y depurar.