Simon Peter (el creador del formato de paquetes autónomos AppImage) hace poco realizo una publicación en GitHub en la cual básicamente pidió realizar un boicot a Wayland «ya que rompe todo».

Uno de los problemas clave, en su opinión, es que con Wayland muchas aplicaciones están dañadas y los desarrolladores de Wayland esperan que los autores de la aplicación arreglen todo ellos mismos.

En el mensaje de la publicación comparte lo siguiente

«Wayland no soluciona ningún problema que tengo, pero rompe casi todas las aplicaciones que necesito. Y permanecen inoperables porque la gente de Wayland parece preocuparse sólo por GNOME y escupir a todos los demás». ¡NO INSTALE WAYLAND! No permita que Wayland destruya todo para que otros no tengan que solucionar problemas más adelante. ¡O promocione más componentes específicos de Red Hat / GNOME (glib, Portals, Pipewire) como dependencias requeridas! «

Dentro de la publicación, comparte algunos de los siguientes ejemplos, en los tipos de aplicación que se «rompen con Wayland»:

Wayland rompe las aplicaciones de grabación de pantalla

• Wayland no es compatible con aplicaciones de grabación de pantalla. Por ejemplo:
  SimpleScreenRecorder: el autor no admitirá Wayland hasta que haya una interfaz estandarizada que no esté vinculada a GNOME.  Roto desde el 24 de enero de 2016, sin resolución («Supongo que usan una interfaz GNOME no estándar para esto»)
• Estudio OBS. Al mismo tiempo, hay un complemento específico de GNOME que le permite usar OBS Studio con Wayland, pero solo cuando usa gnome-shell. Si bien un colaborador activo de OBS Studio señala que la API de captura de pantalla X11 está muy cerca de la peor posible, la situación de captura de pantalla es un buen ejemplo de cómo (GNOME) Wayland retrocedió a algo más difícil de usar que X11 y quizás técnicamente inferior a él.
  Roto desde al menos el 7 de marzo de 2020. («Wayland no es compatible en este momento», «Realmente no hay algo que pueda cambiarse fácilmente. Wayland no proporciona API de captura»)
• https://github.com/mhsabbagh/green-recorder
• https://github.com/vkohaupt/vokoscreenNG/issues/51 Roto desde por lo menos el 7 Mar 2020 ( «Ahora he decidido que no habrá apoyo Wayland por el momento razón de ser, no hay presupuesto para ello vamos a ver cómo se ve en un año o dos..») – Este es el problema clave. Wayland rompe todo y luego espera que otros arreglen los problemas que causó por su cuenta.

Wayland rompe las aplicaciones para compartir pantalla

• Wayland no es compatible con aplicaciones para compartir pantalla. Por ejemplo, jitsi-meet. Al mismo tiempo, por ejemplo, en Fedora 32 es posible compartir la pantalla en sesiones wayland (usando xdg-desktop-portal, que usa Pipewire).
• https://github.com/jitsi/jitsi-meet/issues/2350  roto desde el 3 de enero de 2018
• https://github.com/jitsi/jitsi-meet/issues/6389 roto desde el 24 de enero de 2016 («Cerrando porque no hay nada que podamos hacer desde el lado de Jitsi Meet») . Wayland rompe cosas y deja a los desarrolladores de aplicaciones indefensos e incapaces de arreglar la falla, incluso si quisieran.
• https://github.com/flathub/us.zoom.Zoom/issues/22 Zoom roto desde al menos el 4 de enero de 2019. («No se puede comenzar a compartir, solo admitimos wayland en GNOME con Ubuntu (17, 18), Fedora (25 a 29), Debian 9, openSUSE Leap 15, Arch Linux»). ¡No se sabe nada sobre no GNOME!

Además de ello también menciona que:

• Wayland es incompatible con los menús globales de GNOME.
• Wayland es incompatible con los menús globales del plugin de plataforma de KDE.
• Wayland no es compatible con menús globales basados ​​en Qt.
• Wayland es incompatible con los paquetes de AppImage proporcionados sin un complemento Qt dedicado.

Finalmente el autor de la iniciativa estará encantado de agregar otros ejemplos existentes a su lista si mas personas se unen a la iniciativa e incluso para demostrar que Wayland no es viable.

Lo que si es cierto y que la mayoría de la comunidad de Linux sabe, es que Wayland aún tiene muchos problemas con las aplicaciones de grabación de pantalla (screen recorder), también con aplicaciones de acceso remoto, ya que aún hay varios problemas por solucionar con el manejo del teclado y mouse (un problema bastante viejo y que de manera personal ignoro si ya se ha trabajado para resolver, ya que como menciono es un problema que se había estado arrastrando).

¿Y tú que opinas al respecto?

from Linux Adictos https://ift.tt/3jY7K2H
via IFTTT

Si te apasiona el mundo del videojuego, seguro que ya sabrás lo que es Valve Pressure Vessel. Otro de esos proyectos que cogen nombres de «fontanería» de esta conocida empresa y que ahora podrás explorar de forma minuciosa debido a que sus entrañas (código fuente) está ahora disponible desde GitLab.

Desde hace tiempo Valve ha tenido una cuenta propia en GitHub, ahora propiedad de Microsoft, y desde allí se ha colgado el código fuente para colaborar en los distintos proyectos. Es el caso de proyectos tan importantes como Proton, GameNetworkingSockets, etc. Pero ahora, ha agregado un montón de proyectos a GitLab. ¿Se estará cambiando de «bando»?

Ahora, multitud de esos proyectos que están contenidos en el cliente Steam para Linux han pasado a GitLab, como es el caso de Pressure Vessel. El motivo, parece ser aclarado en estos tweets que puedes ver aquí en el que Timothee Besset contesta a un medio que se pregunta del porqué de este movimiento hacia GitLab:

The projects you see on GitHub are often mirrored from an internal repo. It’s awkward and creates friction for community contributions. The projects on gitlab is where we will do our work in the open.

— Timothee Besset (@TTimo) October 29, 2020

https://platform.twitter.com/widgets.js

Esto no afectará a los usuarios de ninguna manera, así que no hay por qué alarmarse ni nada por el estilo. Todo seguirá igual.

Si aún no sabes qué es eso de Pressure Vessel, puede que te importe poco si está o no en GitLab. Para más información, decirte que es una versión simplificada de Flatpak hecha especialmente para videojuegos. Así se pueden meter los juegos en un pequeño contenedor específico desde el cliente Steam.

Una gran ayuda para desarrolladores que pueden tener un videojuego en un contenedor con el que realizar pruebas, ejecutarlo en cualquier distribución GNU/Linux, y permitir que los juegos antiguos con ciertas dependencias sigan funcionando por mucho tiempo en el futuro (p.e.: recuerda que muchas distros han abandonado el soporte para ciertos paquetes y bibliotecas de 32-bit).

Más información – Ir al repositorio de GitLab con Pressure Vessel

from Linux Adictos https://ift.tt/34UmZ8s
via IFTTT