X11 Server Development Pace Hits A Two Decade Low

[oiaohm]

Of course there is software, which does its own rendering using the backend of choice, and only displays the final image via Xlib XPutImage. But there is also a lot of software, that does not, and people do use them.

In fact the dominate applications on the Linux desktop even skip past XPutimage and go straight to opengl.

XPutimage does not compress. GTK , Qt, Opengl, WXwindows.... the majority of the toolkits these days don't use X11 drawing functions in any big way. Instead heavily use XPutimage or Opengl methods. Those methods are not optimized to be network transparent.

[oiaohm]

If an app is intentionally hostile like "those joke apps from the 90s", I uninstall it the fuck immediately. Why would I use something that clearly might even delete my god damn files?!?!?

Mistake here you wrote uninstall.

https://www.giac.org/paper/gcih/571/x11-forwarding-ssh-considered-harmful/104780

What if you never installed the application Weasel. Yes well documented in 2003 issue with ssh and X11. Problem still exists while we use X11 designs but it got worse its not just SSH that can do attack like this any more.

Weasel think about this what would happen if webbrowsers decided to added the functionality to allow remote control? Also remember this is not theory think chrome remote desktop. Now think if this remote desktop software in browser has some flaw that the functionality can be turned on remotely. This would now be web browser doing the ssh issue with X11. Default X11 install are is going to do nothing to stop the it or require user interaction.

This is the problem its not joke programs from the 90s. But core programs people wish to use today are getting more and more powerful in what they can do by default. Web browsers from the 90s would not have remote desktop or direct hardware access functionality... and a long list of other really scary added features.

Now I fully understand you want to be in control where apps spawn. Most apps are designed so you can customize that. Worst case, you can move them yourself with a script, or the compositor can (nobody said it can't even in X, in fact they do it all the time). But a script can't do this if the compositor doesn't allow it to (since it's just another app).

X11 was designed for a different time. The security landscape is changing. Key applications people may be forced to use may have built in remote control software and be network connected and with webusb direct device access functionality....

Weasel the attack surface is changing. Sandboxing around applications will come very important.

https://www.x.org/releases/X11R7.5/doc/security/XACE-Spec.html

Script not being able to move window without permission can be the case if you are running X11 with XACE enabled. Attempting to use XACE with X11 is a good way to end up with applications malfunctioning badly just because you want a little extra security.

Going forwards sandboxing of applications is going to come more and more important Weasel. You are going to have more and more applications you have to use Weasel that are way too powerful that are internet connected.

We are completely forgetting the Unix rule of do one thing well with webbrowsers instead having them be able to do everything poorly.

When wayland starts the writing was already on the wall that we were heading into a future of overly powerful applications that will need to be sandboxed and permission controlled by users to limit risk of major damage.

[sinepgib]

Mistake here you wrote uninstall.
https://www.giac.org/paper/gcih/571/...harmful/104780
What if you never installed the application Weasel. Yes well documented in 2003 issue with ssh and X11. Problem still exists while we use X11 designs but it got worse its not just SSH that can do attack like this any more.

This has nothing to do with what we're arguing. We're discussing whether applications should be able to position themselves on the screen arbitrarily, not network transparency. Further, Weasel correct me if I'm wrong, but right now we're talking in the abstract, and your link is about concrete implementations. You can make network transparency work without falling for the behavior described in the paper, even if that's not how X11 does it.

I don't get this logic. If your application is hostile to you, why use it? I just don't understand this Wayland bullshit "privacy". Holy shit.

If an app is intentionally hostile like "those joke apps from the 90s", I uninstall it the fuck immediately. Why would I use something that clearly might even delete my god damn files?!?!?

Because the app isn't necessarily attempting to be hostile. Just like MacOS doesn't attempt to be hostile to their users when it does stupid shit like symlinking gcc to clang rather than just not ship it. Then you get confusing errors and have to go through many manual steps to override the idiocy to be able to use the compiler your software was written against.
Sometimes application developers have good intentions that lead to bad UX. Sometimes users have to take the good with the bad because they need the app.
Besides, Linux is no longer meant only for the technologically literate. This means the software should protect the users, at least by default (no need for it to become a walled garden), because they don't know how. We may agree to disagree about whether it should be that way, but that's how things are currently.

Now I fully understand you want to be in control where apps spawn. Most apps are designed so you can customize that. Worst case, you can move them yourself with a script, or the compositor can (nobody said it can't even in X, in fact they do it all the time). But a script can't do this if the compositor doesn't allow it to (since it's just another app).

But app positioning should be per application. That's difference with CSD/SSD, where all apps (that have a titlebar at least, anyway) should share same one.

But if you want that to be customizable it makes more sense to put that customization in the side of the one component responsible for that. I agree it makes sense for the application to be able to politely ask for their position to be remembered. If your window manager supports it, you can tell it's OK to do so. What I don't think is appropriate is for any application to take the role of the window manager ad-hoc at any time. If you (the application) want full control of the screen then just take the whole framebuffer.
The CSD/SSD can very well be allowed or disallowed per application. The point there is not just visual consistency tho, and that's why it's still problematic: the compositor loses control over some important things, like behavior when you try to close the window (essentially, no close button controlled by the compositor in case your application hangs).

[oiaohm]

This has nothing to do with what we're arguing. We're discussing whether applications should be able to position themselves on the screen arbitrarily, not network transparency. Further, Weasel correct me if I'm wrong, but right now we're talking in the abstract, and your link is about concrete implementations. You can make network transparency work without falling for the behavior described in the paper, even if that's not how X11 does it.

Next paragraph sinepgib

Weasel think about this what would happen if webbrowsers decided to added the functionality to allow remote control? Also remember this is not theory think chrome remote desktop. Now think if this remote desktop software in browser has some flaw that the functionality can be turned on remotely. This would now be web browser doing the ssh issue with X11. Default X11 install are is going to do nothing to stop the it or require user interaction.

There are new versions of what is described in that 2004 paper using other software.

Applications arbitrarily positioning self on screen is there a problem with this yes. Web application been able to pop up fake login dialog in the correct location on screen to fool user would be a problem. Remote desktop functionality of chrome of course can move around any window on screen remotely if you are using X11. Will have to ask for permission todo this under Wayland.

sinepgib weasel said he did not understand the need for privacy. Lead Wayland developer being X11 developer starts with the SSH/X11 issue but we have other issues since then. So items like global key capture, be able to move windows around by software... maybe should be behind a permission system.

Sorry to say its not nothing todo with what you are arguing about. Sandboxed application should not be able to arbitrarily, location themselves on screen without permission. We are getting more applications that need to be sandboxed.

[Berniyh]

All Xt based toolkits use Xlib commands for drawing, and those drawing commands are set over the network, not bitmaps. For example, with Motif based nedit, you have a text editor with a nice GUI, menus, syntax highlighting, etc., which works with very low overhead over the network.
https://sourceforge.net/projects/nedit/

Oh dear …
But yeah, that might still work, if it only uses Xlib.
I still don't understand why you would choose that over some text-based editors (and there are a lot great ones out there!), some even allow for mouse events, menus etc.
And a ssh console surely is way more efficient than network transparent X11.
But ok, that's just personal preference.

But mainly I would ask you: is that sort of interface really what the big fuzz is about?
Meaning you're going out into the world telling everybody that X11 is great, because you can use programs like that over the internet?
I'm not convinced.

Also, never mind the fact that programs like these are actually the reason why we have Wayland. Because you can't "fix" the X11 server, because you might end up breaking programs like these that nobody "really" wants.

[guiodic]

Those methods are not optimized to be network transparent.

OpenGL is network transparent. LIBGL_ALWAYS_INDIRECT=1 ensures that opengl instructions are executed by Xorg and thus can be sent from the client via the network to the X11 server, which then actually does the work (with GPU acceleration).

[Weasel]

Weasel think about this what would happen if webbrowsers decided to added the functionality to allow remote control? Also remember this is not theory think chrome remote desktop. Now think if this remote desktop software in browser has some flaw that the functionality can be turned on remotely. This would now be web browser doing the ssh issue with X11. Default X11 install are is going to do nothing to stop the it or require user interaction.

Disable it if you don't want it.

Or don't use Chrome if you can't.

Even if you have to use it, for whatever reason, why would positioning of its windows be your major concern instead of screwing up your files? In this case you need to sandbox it anyway, allowing it to position itself is not even an issue in terms of security, just privacy.

Anytime Wayland prevents a "bad" application from doing something, ask yourself if that application can mess with your personal files. If it can, you shouldn't give a shit about anything else to begin with. Certainly not some privacy bullshit. You need an actual sandbox. Wayland's restrictions are just created by insecure retards.

[oiaohm]

OpenGL is network transparent. LIBGL_ALWAYS_INDIRECT=1 ensures that opengl instructions are executed by Xorg and thus can be sent from the client via the network to the X11 server, which then actually does the work (with GPU acceleration).

https://virtualgl.org/About/Background

guiodic; I wrote not optimized not does not work at all. VirtualGL exists because using LIBGL_ALWAYS_INDIRECT=1 is a very simple way to run out of network bandwidth.

As noted there opengl applications have to use particular opengl features or they are not working by LIBGL_ALWAYS_INDIRECT=1 anyhow.

xpra as well tells you don't send opengl over the network for the same reason if it works you use way too much bandwidth. A single full screen opengl application if it works using LiBGL_ALWAYS_INDIRECT can consume 400Gbps+ network connection totally.. Its good if you want a network pressure test tool not exactly good if you want todo remote desktop. Yes VM on local computer using LIBGL_ALWAYS_INDIRECT=1 to run applicaiton can find self stuffed.

The situation becomes even worse when textures enter the picture. Imagine passing a planar probe through a multi-gigavoxel volumetric dataset such as the Visible Human. The probe will be at least 1 megavoxel in size, meaning that the textures mapped to that probe will occupy at least 3 Megabytes. These textures have to be regenerated on every frame with no reuse of texture data from frame to frame. So, whereas network latency is not as much of an issue in this case, bandwidth definitely is an issue. Even in the best case, a gigabit connection would be required to get anything close to a usable frame rate.

Yes the virtualgl notes a deadly flaw in LIBGL_ALWAYS_INDIRECT guiodic. Absolutely no texture reuse frame to frame. What about shaders guess what absolutely no reuse frame to frame for those as well.

This is a big problem people claim this stuff works. Opengl API is not optimized for remote rendering. LIBGL_ALWAYS_INDIRECT does not fix that problem. Opengl API is optimized for local rendering. Yes LIBGL_ALWAYS_INDIRECT also disabled particular opengl extensions as well that programs can depend on to operate.

guiodic you are using opengl over network by X11 the kind of working solutions are xpra and virtualgl both of those is doing the opengl locally and send image over network.

XPutimage heavy usage runs into the problem the formats used by this are mostly 100 percent not compressed. SSH is able to kind of work around this by it compressing the transmission same with VPNs. Then you have the problem opengl suffers from zero reuse this is one of the thing that leads to the create of xpra so that low bandwidth network connections would let X11 applications work. Xpra adds the feature of if network connections breaks being able to reconnect to application so you don't lose your work as well.

X11 protocol is not a good over network protocol. X11 protocol absolute not optimized for going over network with majority of modern day applications using X11.

Yes xpra over network user end can just have a webbrower because it provides a HTML5 interface. Lot of ways HTML5 provide everything X11 protocol over network does done in even better way. Yes WebGL you have texture and shader reuse so not needing to send many copies over network. Same with images sent over network with HTML5 they are cached and reused.

This is the problem you want X11 protocol to work over network correctly with low latency you will mostly end up re-implementing what has been implemented in HTML already. Not be able to get there cleanly due to all the stuff that has been added to the X11 protocol that is not suitable to cross network.

guiodic yes there is a lot of sales pitched about X11 protocol once you look closer they either don't work or perform badly that users would never want to use them. X11 protocol for over network like it or not is basically obsolete technology that going to cost more resources to fix than it worth.

HTML javascript that allows toolkits to send code to the client end for input validation and for latency hiding. Latency hiding you click on button the javascript is able to make the application button press render happen straight way before the button press is sent over network.

Yes back in history there was a proposal to add a scripting language to X11 protocol this failed because there was not a functional reuse system.

[sinepgib]

OpenGL is network transparent. LIBGL_ALWAYS_INDIRECT=1 ensures that opengl instructions are executed by Xorg and thus can be sent from the client via the network to the X11 server, which then actually does the work (with GPU acceleration).

Huh, that's interesting.

Oh dear …
But yeah, that might still work, if it only uses Xlib.
I still don't understand why you would choose that over some text-based editors (and there are a lot great ones out there!), some even allow for mouse events, menus etc.
And a ssh console surely is way more efficient than network transparent X11.
But ok, that's just personal preference.

But mainly I would ask you: is that sort of interface really what the big fuzz is about?
Meaning you're going out into the world telling everybody that X11 is great, because you can use programs like that over the internet?
I'm not convinced.

Also, never mind the fact that programs like these are actually the reason why we have Wayland. Because you can't "fix" the X11 server, because you might end up breaking programs like these that nobody "really" wants.

While I also don't particularly see the appeal, there are more specific applications for which that may be valuable. I seem to recall some factory control applications were written in FLTK, could be used to remotely follow metrics to see everything was alright and, as happens with most industrial software, will not be ported to any other toolkit any time soon. So I'd say that's actually a valid use for network transparency. But it's also a valid use for X11 as those are not getting ported anywhere anyway. I don't get the hate for Wayland about that, X11 will still be around for those niche use cases. The point is that not everyone has to put up with the downsides that come with it.
X11 will be legacy, but legacy means neither abandoned nor garbage. Legacy pretty much means "not the focus of new development but still necessary".

[oiaohm]

While I also don't particularly see the appeal, there are more specific applications for which that may be valuable. I seem to recall some factory control applications were written in FLTK, could be used to remotely follow metrics to see everything was alright and, as happens with most industrial software, will not be ported to any other toolkit any time soon. So I'd say that's actually a valid use for network transparency. But it's also a valid use for X11 as those are not getting ported anywhere anyway. I don't get the hate for Wayland about that, X11 will still be around for those niche use cases. The point is that not everyone has to put up with the downsides that come with it.
X11 will be legacy, but legacy means neither abandoned nor garbage. Legacy pretty much means "not the focus of new development but still necessary".

FLTK there is a wayland port under development. https://github.com/fltk/fltk/commits...ME.Wayland.txt Yes only appears in 2022.

sinepgib X11 protocol network transparency vs xpra html5 for network transparency vs Weston RDP for network transparency vs xorg vnc server.

Xpra still allows X11 applications over network but you don't have case network connection failing so application failing.. Yes only 1 out of the 4 options that network connection trouble is going to mess up badly is the X11 protocol network transparency.

sinepgib yes network transparency is a wanted feature. But X11 protocol is not required todo it. Think about it you want to use some modern non Linux device what is the odds that it going to come outbox with X11 server on it. This comes the problem X11 end up being pain to setup for network transparency and worse for users. Even the niche cases still using X11 protocol for network transparency are having harder and harder time justifying what they are doing.

Yes the old X11 applications may not be ported forwards but that does not mean that X11 network transparency will be used any distance. Yes some factories you see a raspberry pi cm4 with two network ports put between old X11 network transparency device and network. Yes xpra is running on the pi to make the thing past that point html5. We are seeing the same thing with X11 network protocol as we see with printers to turn old printers into driverless printers.

X11 network protocol and printers that need drivers seam to be on the path of disappearing into history.