Originally posted by jpg44
View Post
This is really quite a disappointment as I have been trying to avoid Wayland, I hope they continue the X version. Wayland is really an idea whose time as come and gone, based on what seemed like at one time a good idea, DRI, now taken to an extreme for even programs that do not need what DRI does. The reason is that Wayland rolls up application and driver into one big ugly mess, and rolls up the display server and window manager into one big ugly mess. This is just a recipe for disaster as you are going to end up with incompatible versions of the application API because of all of the different versions of the display server since every window manager basically impelements its own display server.
The security situation is horrible since putting a hardware driver into an app is a questionable idea that really weakens security rather drastically. The apps should be kept seperate from drivers, and X got this right by having a nice socket between the apps and the display drivers for a nice clean separation.
There is more of a move towards isolation of processes and functions into sandboxes to avoid problems like this can cause like a problem with an app exposing the hardware as an attack surface. Wayland greatly increases the hardware attack surface.
Another stupid thing about Wayland is lack of app <-> display server network transparency so you can run your programs on another computer if need be and display them remotely, this is distinct from remote desktop which is an entire desktop session, rather than a single app.
If wayland were to add functionality for app <-> display network transparency, this would allow for network transparency and also fix the security concerns by allow people a more secure option for keeping apps seperate from the drivers. Just have a DRI/Wayland driver that can be loaded into an app that sends all OpenGL commands over the socket to the Wayland server using RPC and render it with hardware DRI drivers on the server side, and that should do the trick. Why not.
As for the risk of incompatable server implementations, could be addressed by encouraging the use of a fully featured library to provide server functions in the Server.
For those who want to stay on X, please also provide a rootless Wayland server , or a DRI/Wayland driver for apps that simply translates the wayland API to xcb commands and sent as an X client to an X server, that can display Wayland apps to an X server, by proxying and translating Wayland application connections to X client connections which can be targeted at an X server, this would help ensure that even if there are Wayland only applications they can be used on X, this also solves the app<->server network transparency issue since individual Wayland apps could be displayed to an X server.
The security situation is horrible since putting a hardware driver into an app is a questionable idea that really weakens security rather drastically. The apps should be kept seperate from drivers, and X got this right by having a nice socket between the apps and the display drivers for a nice clean separation.
There is more of a move towards isolation of processes and functions into sandboxes to avoid problems like this can cause like a problem with an app exposing the hardware as an attack surface. Wayland greatly increases the hardware attack surface.
Another stupid thing about Wayland is lack of app <-> display server network transparency so you can run your programs on another computer if need be and display them remotely, this is distinct from remote desktop which is an entire desktop session, rather than a single app.
If wayland were to add functionality for app <-> display network transparency, this would allow for network transparency and also fix the security concerns by allow people a more secure option for keeping apps seperate from the drivers. Just have a DRI/Wayland driver that can be loaded into an app that sends all OpenGL commands over the socket to the Wayland server using RPC and render it with hardware DRI drivers on the server side, and that should do the trick. Why not.
As for the risk of incompatable server implementations, could be addressed by encouraging the use of a fully featured library to provide server functions in the Server.
For those who want to stay on X, please also provide a rootless Wayland server , or a DRI/Wayland driver for apps that simply translates the wayland API to xcb commands and sent as an X client to an X server, that can display Wayland apps to an X server, by proxying and translating Wayland application connections to X client connections which can be targeted at an X server, this would help ensure that even if there are Wayland only applications they can be used on X, this also solves the app<->server network transparency issue since individual Wayland apps could be displayed to an X server.
Leave a comment: