3 ms·
Wish I had seen that post of yours then. In short, X11 devs no longer wanted to maintain a huge codebase and decided to restart from scratch, thus, Wayland was
by stelonix 6y ago
Wish I had seen that post of yours then. In short, X11 devs no longer wanted to maintain a huge codebase and decided to restart from scratch, thus, Wayland was born. The recent push toward Wayland adoption and "X IS DEAD LOL" behavior seems to be because KDE and GNOME adopted Wayland, while GNOME was adopted as default DE on Ubuntu. GNOME has an agenda to spread Wayland everywhere and since they're now in the most popular distro, you'll hear more and more that X11 in insecure, abandonware, bloated etc.
If you do check X's codebase though, you'll notice it's very well written and completely maintainable.
As an example, people often say you can fake input on X and therefore it's insecure, but fake input on X (XTEST) sets a boolean send_event that the receiving application can check to see if the event was sent from another application. Most apps ignore that, but Wine drops any event marked as send_event. I do not like this solution. Instead, inter-process access control lists could solve this easily and would not be hard to implement. Yet, some people think throwing 30 years of solid codebase down the toilet and pushing an inferior product is a better solution. Those people have no idea about X programming or its internals and are just echoing a mantra.
- cycloptic 6y agoPlease continue hacking on X if that's your fancy, I agree that the codebase is fine as far as legacy codebases go, the real problem is that the protocol itself has issues and that can't really be changed without breaking backwards compatibility or breaking ABI in xlib. Adding yet another security policy to the X server might fix some issues people have, it unfortunately won't fix all the other problems.
- stelonix 6y agoIt is not impossible to add a new version of the protocol while maintaining backwards compatibility. Applications are Turing machines and there is no such a thing as "impossible". Having a bc path for old connection requests while implementing a new API is entirely possible. There's no abi breakage as I understand it, since it's a client-server model.