X.Org Server 21.1 Will Aim To Release In The Coming Weeks

[oiaohm]

You're right about some apps stopping to render on offscreen or when minimized. That's besides the point. I said that it can, not that it works for every app. The ability to do it means Windows also allows it.

To be correct windows can suspend the drawing of any application who window is offscreen or minimised. There is a difference between can and should. There will be days due to system load that the application you can normally control with autohotkey while they are off screen they will not work. Now if you had used windows at-spi2 equal and the applications support it it would have worked.

Yes if you have FeralInteractive gamemodeor equal or Linux again autohotkey can start screwing up on with offscreen windows being laggy as hell.

Weasel there is a really difference between can and should. Windows allows you to interface with off screen windows but also makes the low CPU priority for their event loops. You said some apps stopping to render on offscreen or when minimised the reality is all do just question by how much. Weasel you have had to had a few cases where what appears at random autohotkey script did not work right. You would not have but 2 and 2 that hey the windows was off screen so am rolling a dice every time if it works.

Weasel its common to think that its only some particular applications that stop render on offscreen or when minimized not that all application can and how much at the mercy of the cpu scheduler. Using the assistance interfaces that are designed to cope with the application being a bit laggy is the safe path for of screen windows.

[binarybanana]

I get it. Those people also missed that its the host file descriptors/handle that is the real problem.

https://lwn.net/Articles/517375/ sorry I got the year wrong it was not 2010 it was 2012. This change from using GEM Buffer or some other GPU vendor buffer solution to host file descriptors/handle is to allow working with the Linux/BSD OS host security. Yes this bring mandatory need for DMA BUF support and GBM features also need to use file handles. So Nvidia has been stubborn for over 9 years on this point at least they are finally coming into line.

This is quite a major security fix so that an application cannot snoop on a output of another application without permission. Like you don't want password dialogs where people is entering password in plaintext to be snoopable.

Trying to make Linux security modules work with X11 server has been a pure nightmare. http://selinuxproject.org/page/NB_XWIN Yes has result in needing X11 server per application.

Wayland you can get away less. Yes just because wayland compositor has a file handle from application to display something on screen does not mean the wayland compositor by the Linux security module has the right to read the contents of that buffer this is a feature that comes from using host file descriptors/handle.

This is something that is required to fix a security fault in the historic X11 server design. This also mean companies like redhat/ibm, suse... making enterprise distributions want to know how the gpu is in fact managing the memory to make sure that stuff that selinux or equal says is high secure does not end up in insecure storage.

People who say there has not been security problems have not looked at why selinux and other parties have jumped though insane number of hoops attempting to secure X11. Reality it should not be anywhere near that hard. The cause is that X11 was another thing design to be host neutral so not integrate with the host OS security.

Yes not being integrated with the host OS security makes implementing security a cluster of horrible hacks that are insanely hard to review if they have achieved the security target.

Please note that nvidia pushing the per vendor buffer solution that is not secure for the past 8-9 years has also stalled work on how to restart the compositor. Think about it with eglstreams since you are using nvidia only private buffer solution this results in the compositor restarts and all the application buffers go away.

Another feature of the file descriptor/file handle on linux. Fun open open a file in a text editor or equal then delete the file off the disc then check the /proc for your text editor you will find that the host file descriptor and the file on disc still exist as long as the text editor kept the file open and has not closed it yet. This is a key requirement to be able to restart a wayland compositor. Heck if we can move to using host file descriptors inside X11 as well in theory it should come possible to restart the X11 server while leaving the windows manager and applications up.

People talk about means to restart the X11 windows manager as wanted feature. People don't think about the elephant in the room why can they not restart the X11 server itself. Part of getting to being able to restart wayland compositors and the x.org X11 server itself without stopping/restarting applications is this change.

Then people talk about restarting graphics drivers. Yes if graphics driver has gone stupid reality here you need to restart the wayland compositor/X11 server as well without killing the applications. MS Windows the compositor can restart due to using windows objects for buffers without restarting applications. Yes Microsoft windows got the means to restart the compositor before any GPU vendors drivers for windows had the means to be restarted. There is a order of operations here.

GPU vendor buffer solution instead of a generic solution has been functionally crippling the Linux desktop. Yes this include GEM buffers and other things like from the open source drivers as well as the Nvidia crud. So GBM or equal support and DMA BUF really are not optional features.

Windows it objects is your generic for buffers. Unix/Posix/BSD/LInux/Mac OS/IOS... you generic host file descriptors/handle for buffers. Its taken us far too long to start fixing this correctly. Yes X11 not being part of the Posix standard has not helped. X11 server internal buffer management is total case of reinvent the wheel 30+ years ago leading to on going security nightmares. Yes it took until 2012 to wake up that this was really the case. Then it taken to 2020 to get Nvidia to wake up that this is also the case. Just because something is decades old does not mean it does not have a fundamental mistake.

You don't need anything special for that. Just don't cash the client when X disappears and connect to it once it comes up again. This could be easily solved at the toolkit level. It requires some way to recreate some of the lost state, create new GL context and such, but it's not like GTK uploads icons as pixmaps into the X server (or GL driver) and deletes them from your HDD.

[ssokolow]

People talk about means to restart the X11 windows manager as wanted feature. People don't think about the elephant in the room why can they not restart the X11 server itself. Part of getting to being able to restart wayland compositors and the x.org X11 server itself without stopping/restarting applications is this change.

Then people talk about restarting graphics drivers. Yes if graphics driver has gone stupid reality here you need to restart the wayland compositor/X11 server as well without killing the applications. MS Windows the compositor can restart due to using windows objects for buffers without restarting applications. Yes Microsoft windows got the means to restart the compositor before any GPU vendors drivers for windows had the means to be restarted. There is a order of operations here.

Generally, people talk about "make it work for me" and assume anything more is impossible/unfeasible for reasons beyond their ken.

The nVidia driver versions chosen by Canonical have been stable enough that, in a decade, I've only hit one driver version that I noticed a leak in and one driver version that crashed, while the version of KWin in Kubuntu 20.04 LTS is the first WM I've ever had that can go more than two or three weeks without needing a restart... and only with compositing disabled. It starts to freak out and start drawing the windeco as solid black within a day or two with compositing enabled.

[ssokolow]

Re-read the paragraph, this statement had nothing to do with file or object based. The point being made is putting these security features into Wayland is kinda pointless because the way that Linux is designed, unless you also restrict the data that the program can access then you are not really solving anything. https://blog.martin-graesslin.com/bl...plasmawayland/ is a good explanation

This is what I meant when I said putting the cart before the horse, making Wayland really secure is kind of pointless because in context of the security that Wayland is providing (I.e. a random program not being able to take another programs clipboard), Linux programs can do this without Wayland anyways.

Note that he says "Overall it means that Plasma 5.5 on Wayland is not yet able to provide the security I would have liked to have, but it’s still a huge improvement over X11." (emphasis mine)

I only skimmed over that article, but I don't see any mention that they reverted the "Wayland prevents Flatpak/snappy-sandboxed applications from using X11 as a sandbox-escape vector via something like synthesizing keys to trigger and fill a Run dialog"... just that, if you're attacking an application that's installed through a more traditional un-sandboxed method, it's still possible to write a keylogger.

KWin should still be wayland-level secure against applications running in sandboxed package-delivery systems like Flatpak which deny access to things like modifying the user's session startup scripts, so it's a step forward, and, unlike with X11, any unsafe APIs between Plasma and KWin aren't considered "stable and public" enough for a new "XSECURITY's adoption was foiled by having too many non-negotiable third-party applications break if you enable it" to happen when they rearchitect to close the holes later.

[ssokolow]

You're right about some apps stopping to render on offscreen or when minimized. That's besides the point. I said that it can, not that it works for every app. The ability to do it means Windows also allows it.

That's not exactly a strong argument when it can also be used to argue in favour of eliminating memory protection and going back to the un-protected "any application can monkey-patch any memory location on the entire system" memory model of MS-DOS and 8-bit micros.

It's always a trade-off, and switching from "let anyone build their own interfaces" to "use clearly defined APIs" sacrifices agility in favour of stability. Sure, you can't just have any arbitrary application monkey-patch anything to get something done, but you force-guarantee that changing/adding one application is less likely to cause other things to break.

[mppix]

Actually you are cherry picking his statements out of context, you evidently didn't watch the whole video because he also clearly stated that he is pissed that desktop environments are constantly breaking things and he a made an apt comparison about how the Linux maintainers/kernel bends over backwards to try, as much as possible, to not break things (including when it conflicts with good design). He even made a point about how Windows is much better than Linux is this regard because you can just run some old binary that was packaged 15 years ago where as with Linux underlying critical libraries tend to historically break in one way or another (or they just remove old libraries that they think no one is using anymore). In context of your point about Ubuntu keeping the 32 bit packages, this is precisely an example of what he was talking about where either DE like gnome and/or distributions decide randomly on a whim to remove/change things that break running programs for users.

One of the reasons for subsurface not bothering to do distributions was this point. Of course there are other reasons (such as it being a pain to make packages for so many linux distors) but this is also a fairly minor point since nothing is stopping you from making packages for the major distributions, and subsurface didn't even bother with this because of the previous point.

What are you talking about?
Subsurface has multiple Linux releases and here is the link

https://subsurface.github.io/download/

And if (big if) Linux 'constantly breakes userspace', flatpak (and similar) solves this issue for you.

[oiaohm]

You don't need anything special for that. Just don't cash the client when X disappears and connect to it once it comes up again. This could be easily solved at the toolkit level. It requires some way to recreate some of the lost state, create new GL context and such, but it's not like GTK uploads icons as pixmaps into the X server (or GL driver) and deletes them from your HDD.

Really do not crash the client is the tricky bit that Nvidia has been in the way with. You don't want nvidia eglstreams issue where you restart the GPU for setting up the compositor and now all the memory the client applications have are now segfaults. This why GBM support as long Nvidia does it right will be important because the per process allocation of particular things is required to prevent restarting X11 bare metal or wayland compositor result in crashed applications due to segfault.

Remember the data that turns from existing to the application to being segfault with Nvidia model means you have lost a lot state

GTK uploads icons as pixmaps into the X server (or GL driver) and deletes them from your HDD.

This is correct but this is another problem. Lets say let the memory be nuked as Nvidia drivers have wanted to. Now all your open applications what IO access on the SSD/HDD to restore all the data they have lost. System now not very power effective and is now stalling out. It works out better to let the application crash than force going back to SSD/HDD in mass.

Nvidia working on supporting GBM and DMA BUF are big things. X11 conference coming up there is a talking on allowing wayland compositor to restart and possible even be replaced. Of course once that works X11 bare metal may be able to work in this direction as well.

Per process allocation of graphical stuff is like the first step and has to be. There is a reason why wayland is using file handles in the form of dma buf to pass stuff to the compositor this means that allocation can remain in the client applications memory allocation. Remaining in the client applications ram memory means if the compositor goes away you are not going to the ssd/hdd and you are not triggering massive IO load in a short time frame. So you are not stalling the interface out any longer than it needs to be.

There is quite a bit of forwards planning in the wayland design. Its just getting around to having all the pieces assembled.

https://www.youtube.com/watch?v=SNKzVYUEr7k Akademy 2021 - Addressing Wayland Robustness

Shows the start of the process going to wayland compositor being able to restart.

[mdedetrich]

What are you talking about?
Subsurface has multiple Linux releases and here is the link

https://subsurface.github.io/download/

And if (big if) Linux 'constantly breakes userspace', flatpak (and similar) solves this issue for you.

Not at the time Linus made that video, subsurface only started making Linux releases somewhat recently. But again, you missing (likely deliberately) the whole point being made ergo your uneducated remark about users being idiots because of backwards breaking changes.

Note that he says "Overall it means that Plasma 5.5 on Wayland is not yet able to provide the security I would have liked to have, but it’s still a huge improvement over X11." (emphasis mine)

I only skimmed over that article, but I don't see any mention that they reverted the "Wayland prevents Flatpak/snappy-sandboxed applications from using X11 as a sandbox-escape vector via something like synthesizing keys to trigger and fill a Run dialog"... just that, if you're attacking an application that's installed through a more traditional un-sandboxed method, it's still possible to write a keylogger.

KWin should still be wayland-level secure against applications running in sandboxed package-delivery systems like Flatpak which deny access to things like modifying the user's session startup scripts, so it's a step forward, and, unlike with X11, any unsafe APIs between Plasma and KWin aren't considered "stable and public" enough for a new "XSECURITY's adoption was foiled by having too many non-negotiable third-party applications break if you enable it" to happen when they rearchitect to close the holes later.

Sure I don't disagree with what you are saying here but the critical point here is that optional security is by definition not secure. Yes its possible to sandbox applications via flatpak (like you said, although the degree is debatable) but not all applications are forced to run through flatpak.

This is what I was referring to when I said earlier that for this kind of security to actually work properly, it needs to be non optional. The best way to implement this capability based system in the kernel (i.e. fuschia), or with a system like Android due to the ecosystem design everyone is forced to distribute apps on a single platform (apk's). This also helps enforce that your ecosystem of applications actually takes security seriously, otherwise you get this problem https://www.flatkill.org/2020/

[furtadopires]

Regressions (only) on specific platforms, and (only) with less common hardware, and with inadequate testing resources, and with unresponsive maintainers, are part of the experience a release manager knowingly takes on. Whether any of those issues will occur for this release is currently unknown, but if they do occur, they tend to be quick burnout points for release managers, especially independent ones, as without the backing of a large corp that can choose to purchase one of (almost) everything for testing, and to provide backup support for the release manager, the potential impact on evaluating resolutions and completing a release cannot be overstated.

Regression are regressions, and if those happens they have do be fixed. "Less common hardware" can be a big list and affect users in some way that can take some time to be identified (and more to be properly reported). Let's say this affects some company setup, they might demand this regression to be fixed or just rollback the changes, wasting all this update effort.

And before you think I'm cheering against x11, my doubt is legitimate since x11 being hard to maintain is what caused wayland to be develop in the first place.

Thats not surprising considering that remote functionality on Wayland is not even a real standard so I can understand why a software like AnyDesk wouldn't support it because it would be a massive pain in the ass (this is another problem with Wayland).

Remoting with X11 is ultra easy, every compositor that implements it gets remoting capabilities for free and AnyDesk doesn't need to care if you run i3, gnome KDE etc etc

Pipewire and xdg-desktop-portal are some things for a while, and both of then aren't compositor-specific, OBS already make use of then for screen sharing, and while I agreed that they shouldn't drop x11, they also shouldn't ignore wayland if your main product involves working with display. An alpha version for testing would be better than the "just use x11" in this case.

Also, Anydesk is just one example, I bet there are others holding wayland support due to x11 existance as default in a lot of distros, despite the lack of official support for a while, and my critic is about people using this argument to avoid necessary updates. You wouldn't like someone telling you to "just use another DE" if you're having problems with your setup.

[ssokolow]

This also helps enforce that your ecosystem of applications actually takes security seriously, otherwise you get this problem https://www.flatkill.org/2020/

Ahh, the famous FUD site that:

• Tries to claim that GNOME UX idiocy is proof that Flatpak itself is fatally flawed.
• Uses statements that have been tested and proven false in reply posts, like "Almost all popular apps on Flathub"
• Uses bombastic prose, makes no effort to steer readers in a productive direction, and just trashes on Flatpak.
• Has no byline or other indication of who's responsible for writing it or how to contact them with corrections and seems to have left the registrant information empty in the domain's WHOIS. (If OVH offers an internal "fill our ReCAPTCHA to get the full record" system with more info, I can't find it.)

To be honest, it's only a little bit of colour and font size variation away from being Time Cube... and at least Time Cube's author was honest enough to tell you who he was. (Hell, at least Time Cube had enough character for people to make parody sites like Slime Cube and Game Cube.)