El trabajo dentro de Fedora no para y es que los desarrolladores han dado de que hablan nuevamente y en esta ocasión no es sobre la próxima version de Fedora 33 sino que ya también se encuentran centrados sobre Fedora 34.

Y es que recientemente en las listas de correo ha comenzado a surgir diversos debates sobre varios cambios propuestos para esta version de la distribución. Uno de los cambios que se propone es la eliminación del soporte para la desactivación del tiempo de ejecución de SELinux.

En donde para la implementación en Fedora 34, se describe un cambio para eliminar la capacidad de deshabilitar SELinux en tiempo de ejecución.

Mientras que se conservará la capacidad de cambiar entre los modos «enforcing» y «permissive» durante el arranque. Después de la inicialización de SELinux, los controladores de LSM se colocarán en modo de solo lectura, lo que mejora la protección contra ataques dirigidos a deshabilitar SELinux después de explotar vulnerabilidades que podrían cambiar el contenido de la memoria del kernel.

Para deshabilitar SELinux, solo se deberá reiniciar el sistema con el parámetro «selinux=0» en la línea de comando del kernel.

Además de que se menciona que no se admitirá la desactivación cambiando la configuración de /etc/selinux/config (SELINUX = disabled). Anteriormente, el soporte para descargar el módulo SELinux estaba obsoleto en el kernel de Linux 5.6.

El soporte para la desactivación del tiempo de ejecución de SELinux a través de »/etc/selinux/config » fue desarrollado originalmente para facilitar que las distribuciones de Linux soportaran arquitecturas en donde agregar parámetros al comando del kernel era difícil.

Desafortunadamente, admitir la desactivación del tiempo de ejecución significó que tuvimos que hacer algunas compensaciones de seguridad cuando se trata de los ganchos de LSM del kernel.

Marcar los ganchos LSM del kernel como de solo lectura proporciona algunos beneficios de seguridad, pero significa que ya no podemos desactivar SELinux en el runtime.

Otro de los cambios que se ha mencionado dentro de las listas de correo para Fedora 34, es que se propone cambiar las compilaciones predeterminadas con el escritorio KDE para usar Wayland por defecto, con lo cual está previsto que la sesión X11 sea una opción.

Actualmente, el trabajo de KDE en la parte superior de Wayland es experimental, pero en KDE Plasma 5.20 este modo de operación se equipará en funcionalidad con el modo de operación en la parte superior de X11.

==== ¿Wayland está listo? ====
Wayland se ha utilizado de forma predeterminada para Fedora Workstation desde Fedora 25. Y aunque inicialmente era algo inmaduro, hoy es una experiencia muy sólida en prácticamente todo.

En el lado de KDE, el trabajo serio para apoyar a Wayland comenzó en breve después de que GNOME cambiara a Wayland por defecto. A diferencia de GNOME, KDE tiene una mucho más amplio en su conjunto de herramientas, y ha tardado más en llegar a un estado utilizable. Con la versión Plasma 5.20, el protocolo Wayland para
finalmente se admiten screencasting y pegar con el botón central,
completando el conjunto de funciones requerido para cambiar a Wayland
defecto.

La inclusión de la sesión de KDE 5.20 basada en Wayland abordará los problemas de screencast y clic central. El paquete kwin-wayland-nvidia se utilizará para funcionar cuando se utilicen controladores patentados de NVIDIA. La compatibilidad con X11 se proporcionará a través del componente XWayland.

Como argumento en contra de mantener la sesión por defecto basada en X11, se menciona el estancamiento del servidor X11, que prácticamente ha detenido el desarrollo en los últimos años y solo se están realizando correcciones para errores peligrosos y vulnerabilidades en el código.

==== ¿Qué pasa con NVIDIA? ====
Plasma, de hecho, «sí» es compatible con las GPU NVIDIA con la propiedad conductor en Wayland. Debe activarse manualmente, que será atendido por el paquete <code> kwin-wayland-nvidia </code>. Entonces la expectativa es que todas las GPU principales funcionen bien.

Mover la compilación predeterminada a Wayland estimulará más actividad de desarrollo relacionada con el soporte de nuevas tecnologías gráficas en KDE, ya que a su debido tiempo el desarrollo se reflejó en la transferencia a Wayland de la sesión de GNOME en Fedora 25.