GNOME Shell ha sido un entorno polémico desde el primer lanzamiento, dejando bastante polarizada a la comunidad en torno a su propuesta, con discusiones que abarcan desde la disposición de la interfaz de usuario hasta su arquitectura interna.
Uno de los elementos que más debates generan es la utilización de JavaScript, la conocida tecnología que en su momento fue concebida con la intención de crear páginas web dinámicas desde el lado del cliente (el navegador web), pero que actualmente es utilizada en campos muy diferentes, abarcando hasta tecnologías que trabajan a nivel de servidor como Node.js.
Con la expansión de JavaScript más allá de la web, los responsables de GNOME decidieron seguir la tendencia y utilizar esta tecnología para shell del entorno de escritorio, una decisión que, según explica Jiri Eischmann en su blog, se tomó hace 10 años debido a la gran cantidad de experimentos que se estaba haciendo con la interfaz de usuario, algo a lo que se unió su gran popularidad, lo que podría ayudar en la tarea de encontrar programadores dispuestos a implicarse.
La elección de escribir la Shell en JavaScript tuvo una consecuencia, y es que resulta fácil de parchear y alterar su comportamiento. Esto hace que mediante las extensiones se apliquen parches al mismo código de GNOME Shell, pudiendo cambiar sin límites el comportamiento y la apariencia del entorno, pero también se abre la puerta a introducir focos de inestabilidad por errores o incompatibilidades.
En un principio los desarrolladores de GNOME se mostraron algo reacios a las extensiones, pero estas se volvieron muy populares y tuvieron ceder. Además, las extensiones resultaron ser muy fáciles de manejar y con pocos requisitos a nivel pasos, lo que también ayudó a impulsar su expansión entre los usuarios. Pero no todas las extensiones están igual de bien hechas, por lo que algunas pueden incluso provocar un reinicio de la shell o Mutter tras un cuelgue previo de la sesión en Xorg.
Wayland se convirtió en el servidor gráfico por defecto de GNOME en 2016, y aquí los problemas de estabilidad fueron a peor. Con Xorg, cuando el entorno se cae, este se recupera y el usuario sigue por donde estaba, pero por una decisión de diseño se unió Mutter (el compositor de los elementos gráficos) al proceso de GNOME Shell, por lo que en caso de caída de la shell se lleva por delante el compositor, provocando que exista un riesgo de perder el trabajo no guardado en las aplicaciones abiertas.
En otras palabras, se puede decir que desde GNOME reconocen algunos fallos que están complicando el mantenimiento de algunas decisiones tomadas en su momento. Con el fin de ofrecer una solución para al menos mejorar la situación, Jiri Eischmann ha puesto sobre la mesa las siguientes posibilidades:
- Tener más cuidado con las extensiones utilizadas, inhabilitándolas todas en caso de tener un cuelgue del entorno. Cuando el usuario vuelva a habilitarlas se le tiene que comunicar que posiblemente sea una de las extensiones la que esté provocando el problema con la sesión de GNOME Shell sobre Wayland.
- Desacoplar GNOME Shell y Mutter y/o realizar otros pasos para recuperar el mismo comportamiento que con Xorg, o sea, que un cuelgue del entorno no se lo lleve todo por delante, algo que requeriría de importantes cambios en la arquitectura. Lo propuesto aquí es lo que hace Plasma 5, en el que la interfaz de usuario (plasmashell) y el compositor (Kwin) funcionan en procesos separados.
- Descontinuar las extensiones sin límites mediante la introducción de una API limitada que sustituiría al parcheo de código del propio GNOME Shell. Esto volvería imposible la reimplementación de algunas extensiones existentes.
Si por algo es conocido GNOME Shell es por la introducción de restricciones en la experiencia de usuario, con algunas propuestas que han generado agrios debates. Sin embargo, resulta paradójico ver cómo las extensiones pueden modificar sin límites el código JavaScript del propio GNOME Shell, permitiendo la introducción de grandes modificaciones.
