GNOME, El Señor de las Polémicas: la Comunidad de las Extensiones Eliminadas

Empiezo hoy con este título tan original debido a que GNOME Shell, la rama actual de desarrollo del clásico escritorio GNOME, en los últimos años, va de polémica en polémica y tiro porque me toca. Y esta vez no va a ser menos.

Uno de los principales motivos por el cual GNOME todavía sigue siendo muy utilizado es por la presencia de extensiones que mejoran de forma evidente la experiencia de usuario dentro de este entorno de escritorio. Debido a que este entorno usa Javascript en su capa de usuario (o "shell") es relativamente fácil crear una extensión de este estilo. Obviamente, las extensiones pueden mejorar o empeorar la experiencia de usuario en función de cómo interactúan con el servidor gráfico. Y aquí tenemos el segundo ingrediente de la ecuación. Algunas extensiones pueden llegar a "colgar" a Xorg, el servidor gráfico clásico de Linux (y el de GNOME hasta 2016). Tras un cuelgue, es posible recuperar la sesión sin mayores problemas, y sin ninguna pérdida de documentos. Sin embargo, hace 2 años, este entorno de escritorio cambió a Wayland como servidor gráfico (o programa que permite el "dibujo" de la interfaz del usuario en Linux). Esto, unido con decisiones de diseño un tanto drásticas (Mutter como compositor; o "dibujante" de las pantallas en Linux), provocaron un aumento de la inestabilidad general, llegando a provocar una posible pérdida de la sesión gráfica (y de datos en caso de tenerlos abiertos en programas en el momento del cuelgue) en los mismos casos de uso que Xorg.

Hace unos días, uno de los desarrolladores de GNOME, publicó un comunicado en el que reconocían este, y otros tantos errores que han provocado que el GNOME Shell de hoy sea, para la mayoría de usuarios, un entorno de escritorio muy poco fiable. Entre esos errores, ha destacado las extensiones como una de las causas más frecuentes de inestabilidad. Y ha propuesto tres soluciones, a aplicar de cara a versiones futuras del Shell:

1-(la solución "suave") Inhabilitar las extensiones de GNOME instaladas en caso de cuelgues.
2-(la solución "complicada de implementar y time and resources-consuming", como dirían los ingleses) Separar la interfaz de usuario y el compositor de interfaz de usuario, al estilo de KDE Plasma. Obviamente esto podría arreglar bastantes problemas de estabilidad, pero tardaría mucho tiempo y recursos en realizarse, incluso años, cosa que la mayoría de desarrolladores de GNOME rechazan.
3-(la solución "desproporcionada") Creación de una nueva API limitada para extensiones (Hola, soy Foxie McClure. Tal vez me recuerden de otras reescrituras de API como las WebExtensions, las famosas extensiones capadas, o la puesta en obsolescencia de XUL en favor de un nuevo motor desarrollado desde cero). Puede ser que hayáis captado la ironía perfectamente. Sí, una API nueva y acotada sería, básicamente, el fin de las actuales extensiones tal y como están desarrolladas. Debido al historial de problemas que GNOME ha presentado en los tiempos recientes para con los usuarios, una acción de este estilo podría significar la migración de usuarios a otros entornos de escritorio de una forma instantánea.

Y hasta aquí llega la explicación del desarrollador. Ni que decir tiene que esto ya ha creado discusiones por aquí y por allá , así que, puede ser un buen tema de debate.

Y vosotros, ávidos lectores, ¿qué opináis de toda esta parafernalia? Nos vemos en los comentarios

Aquí podéis leer una replica de los chicos/as de KDE sobre el tema de las extensiones → blogs.kde.org/2018/08/02/engineering-pla...4-present-and-future