>i don't think it has a huge impact on the discussion here. but this is such a key difference versus X, that i think is hugely under-told: Wayland compositors all rely on lots of kernel facilities to do the job, where-as X is basically it's own kernel, has origins where it effectively was the device driver for the gpu, talking to it over pci, and doing just about everything. when people contrast wayland versus X as wayland compositors needing to do so much, i can't help but chuckle, because it feels like the kernel does >50% of what X used to have to do itself; it's a much simpler world, using the kernel's built-in abstractions, rather than being multiple stacked layers of abstractions (kernels + X's own).
Are you an AI bot? Modern X11 server using DRM are more than 20 years old. You are talking about how X11 servers worked in the 90's
"Update: On June 8th, 2024, I submitted this privacy policy to Google, and on June 10th, they accepted it. I take this to mean that they found it to be 100% factual and endorse it entirely. XScreenSaver was restored to the "Play" [sic] store, and people were able to again downloaded and enjoy it freely.
But then!
Barely 6 weeks later, on July 24th, 2024, Google instituted yet another new policy: basically they told me that if I didn't give them a sample of my blood a copy of my driver's license, they would remove XScreenSaver from the "Play" [sic] store, again.
Obviously that's never going to happen. Do I, the person who wrote the above list cataloging Google's various predations, seem like the sort of person who would willingly give Google my private details? On purpose? I do not think so.
Having distributed XScreenSaver for over a decade to I-don't-even-know-how-many users (I actually don't know, I never looked) Google suddenly decided that it was a huge problem that they don't have a lock of my hair.
Since I enjoy wasting the time and money of multinational superpredators, I spent a few weeks going back and forth with what passes for developer "support" over there. You can read about it over on my blog. Eventually they just started ignoring my emails, and in November 2024, XScreenSaver was again de-listed from the Google "Play" [sic] store, presumably this time for good.
However, we can take solace in the fact that Google endorsed the above privacy policy, and found no fault with it whatsoever."
The standard POSIX specification describes the vi line editing mode for the shell command line. They tried to add an emacs mode but... [1]
"In early proposals, the KornShell-derived emacs mode of command line editing was included, even though the emacs editor itself was not. The community of emacs proponents was adamant that the full emacs editor not be standardized because they were concerned that an attempt to standardize this very powerful environment would encourage vendors to ship strictly conforming versions lacking the extensibility required by the community. The author of the original emacs program also expressed his desire to omit the program. Furthermore, there were a number of historical systems that did not include emacs, or included it without supporting it, but there were very few that did not include and support vi. The shell emacs command line editing mode was finally omitted because it became apparent that the KornShell version and the editor being distributed with the GNU system had diverged in some respects. The author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions. Although the KornShell author agreed to consider changes to bring the shell into alignment, the standard developers decided to defer specification at that time. At the time, it was assumed that convergence on an acceptable definition would occur for a subsequent draft, but that has not happened, and there appears to be no impetus to do so. In any case, implementations are free to offer additional command line editing modes based on the exact models of editors their users are most comfortable with."