|
|
Subscribe / Log in / New account

LWN's unreliable predictions for 2022

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 19:17 UTC (Tue) by dtlin (subscriber, #36537)
In reply to: LWN's unreliable predictions for 2022 by Wol
Parent article: LWN's unreliable predictions for 2022

It needs a graphical session, which is somewhat unofficially defined by systemd/udev/pam, but I'm not sure how you interpret that as needing part of the X stack?


to post comments

LWN's unreliable predictions for 2022

Posted Jan 4, 2022 21:06 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

All I know is, that while I was trying to debug why plasma would (or wouldn't) launch at random, I ended up on what I remember as an official plasma site saying that launching from the command line was DEFINITELY unsupported, experimental, and likely to go wrong. And it also said that plasma/qt5, as originally written, had a lot of deeply entrenched X dependencies, which were slowly being removed but it was a major undertaking.

And from what I can make out, Wayland is X13 - I seem to remember someone saying that if you modularised everything you could in X you would end up with something very similar to Wayland, and Wayland has re-used everything it can from X, so the two are pretty tightly coupled. However, starting from very different security paradigms they're incompatible at the base level. But seeing as you can have "X over Wayland" or "Wayland over X", I'm not sure where in all this Plasma fits in ...

Cheers,
Wol

LWN's unreliable predictions for 2022

Posted Jan 12, 2022 20:13 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

> I seem to remember someone saying that if you modularised everything you could in X you would end up with something very similar to Wayland, and Wayland has re-used everything it can from X, so the two are pretty tightly coupled

This is... extremely not true. Very extremely not true.

LWN's unreliable predictions for 2022

Posted Jan 17, 2022 5:26 UTC (Mon) by flussence (guest, #85566) [Link] (2 responses)

At this point in time it's sort of true, but only because nobody in their right mind writes X programs without a mountain of abstraction layers. Even the core X11 protocol is insulated behind xcb nowadays because it's *painful* without it.

LWN's unreliable predictions for 2022

Posted Feb 19, 2022 1:24 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

> Even the core X11 protocol is insulated behind xcb nowadays because it's *painful* without it.

Buh what? This too is basically the reverse of reality as I understand it. Everyone not doing something very strange used libX11 to interface with the X protocol for decades; almost nobody sent raw protocol messages. XCB is an attempt to get *closer* to the protocol, not further from it.

LWN's unreliable predictions for 2022

Posted Feb 26, 2022 6:40 UTC (Sat) by flussence (guest, #85566) [Link]

I explained that one badly, that's on me. The point is that libxcb's both better for the developer and the computer than the old "reference" implementation (libXfoo), where everything was synchronous API calls. X11 hasn't changed but the main way of interfacing with it is now completely different.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds