4 ms·

So this means we really need Wayland. Hope that somebody puts a EOL like Flash on X. Only then will all those projects move to Wayland. Even Python 2 to 3 took

So this means we really need Wayland. Hope that somebody puts a EOL like Flash on X. Only then will all those projects move to Wayland. Even Python 2 to 3 took well over a decade and we still haven't reached EOL.

nly 9y ago
I dunno... modern X (XCB) doesn't seem so different to Wayland. Both are asynchronous RPC protocols with bindings generated from a bunch of XML specs. Both use shared memory aggressively. Both share a lot of concepts. X just has more back-compat to deal with.
- nhaehnle 9y ago
  People over-emphasize a lot of the problems X has. A lot of the real original problems like high latency were evolved away. And while backwards compatibility can be annoying, that's just what you get for trying to do serious software engineering. So I agree with you that the differences between X and Wayland are greatly exaggerated. However, there is one significant architectural difference between X and Wayland that is quite difficult to evolve away. In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. In Wayland, there are only two: the client (app) and the compositor. The X design is more fragile (state managed in 3 places instead of 2) hence ICCCM, and has more latency and overhead. However, it made a lot of sense back when the X server talked to the hardware directly and therefore needed both an integrated driver and special privileges. It'd be silly to implement drivers as part of compositors, so the separation of mechanism and policy was the right way to go back then. Since then, however, the mechanism has basically entirely moved into the kernel (DRM/KMS) and Mesa (OpenGL). This happened in bits and pieces first with the evolution of the DRI protocol and then the jump to kernel mode setting. That is the evolutionary development which lead to the move to Wayland makeing sense. I suppose this 3-to-2-process transition could have been evolved by refactoring the core of the X server source (the whole protocol handling etc.) into a library that compositors then simply link against. But that would have been a truly herculean task with not very many natural intermediate steps. Implementing something like Wayland from scratch on the modern Linux graphics stack is actually much less work -- except perhaps for transitioning all the toolkits, but then again, the X server source lends itself fairly well to writing various "X-on-something-else" servers, since people have been doing that for a while, so there's a natural if slightly awkward solution for backwards compatibility. So hacking up an initial prototype for Wayland could be done very quickly, but note that actual adoption still took a long time. But the point is that the Wayland path had more presentable intermediate steps (unlike the X server refactor), so that's the path that software evolution took. (Man, this got a lot longer than originally intended...)
  - nly 9y ago
    > In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. Is the compositor not optional?
    - digi_owl 9y ago
      IT should be, but i fear it is more and more taken for granted...
    - nhaehnle 9y ago
      Even if you don't have a compositor you still have at least a window manager, which has much the same issues (high latency, ICCCM).
- digi_owl 9y ago
  Well they were pretty much written by the same people, not that i have much love for XCB (as a project) as it has lead to some recompiling on my end...
- deleted 9y ago
  [deleted]
quotemstr 9y ago
I still Wayland is a titanic mistake and that X could have been extended indefinitely instead without a flag day, without weird breakages, and without any loss of core features.
- kronos29296 9y ago
  With a load of backwards compatibility for devices that don't make sense for a normal usage and patches for patches that were written fix bugs which were written to extend X. Better to start from scratch IMO.
  - quotemstr 9y ago
    I don't see the backward compatibility burden being very high. The core protocol just keeps working.
    - kronos29296 9y ago
      Microsoft spends millions for backward compatibility and they charge a fortune for that. This is an open source project with not as much resources and the core protocol of X was never made for GUI. It was made for displaying a cute clock on the screen when there was no concept of GUI. They extended it to do something it was never meant to do. Youtube talk about it: https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44

nly 9y ago

I dunno... modern X (XCB) doesn't seem so different to Wayland. Both are asynchronous RPC protocols with bindings generated from a bunch of XML specs. Both use shared memory aggressively. Both share a lot of concepts. X just has more back-compat to deal with.

nhaehnle 9y ago
People over-emphasize a lot of the problems X has. A lot of the real original problems like high latency were evolved away. And while backwards compatibility can be annoying, that's just what you get for trying to do serious software engineering. So I agree with you that the differences between X and Wayland are greatly exaggerated. However, there is one significant architectural difference between X and Wayland that is quite difficult to evolve away. In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. In Wayland, there are only two: the client (app) and the compositor. The X design is more fragile (state managed in 3 places instead of 2) hence ICCCM, and has more latency and overhead. However, it made a lot of sense back when the X server talked to the hardware directly and therefore needed both an integrated driver and special privileges. It'd be silly to implement drivers as part of compositors, so the separation of mechanism and policy was the right way to go back then. Since then, however, the mechanism has basically entirely moved into the kernel (DRM/KMS) and Mesa (OpenGL). This happened in bits and pieces first with the evolution of the DRI protocol and then the jump to kernel mode setting. That is the evolutionary development which lead to the move to Wayland makeing sense. I suppose this 3-to-2-process transition could have been evolved by refactoring the core of the X server source (the whole protocol handling etc.) into a library that compositors then simply link against. But that would have been a truly herculean task with not very many natural intermediate steps. Implementing something like Wayland from scratch on the modern Linux graphics stack is actually much less work -- except perhaps for transitioning all the toolkits, but then again, the X server source lends itself fairly well to writing various "X-on-something-else" servers, since people have been doing that for a while, so there's a natural if slightly awkward solution for backwards compatibility. So hacking up an initial prototype for Wayland could be done very quickly, but note that actual adoption still took a long time. But the point is that the Wayland path had more presentable intermediate steps (unlike the X server refactor), so that's the path that software evolution took. (Man, this got a lot longer than originally intended...)
- nly 9y ago
  > In modern X, there are actually three processes involved: the client (app), the X server, and the compositor. Is the compositor not optional?
  - digi_owl 9y ago
    IT should be, but i fear it is more and more taken for granted...
  - nhaehnle 9y ago
    Even if you don't have a compositor you still have at least a window manager, which has much the same issues (high latency, ICCCM).
digi_owl 9y ago
Well they were pretty much written by the same people, not that i have much love for XCB (as a project) as it has lead to some recompiling on my end...
deleted 9y ago
[deleted]

quotemstr 9y ago

I still Wayland is a titanic mistake and that X could have been extended indefinitely instead without a flag day, without weird breakages, and without any loss of core features.

kronos29296 9y ago
With a load of backwards compatibility for devices that don't make sense for a normal usage and patches for patches that were written fix bugs which were written to extend X. Better to start from scratch IMO.
- quotemstr 9y ago
  I don't see the backward compatibility burden being very high. The core protocol just keeps working.
  - kronos29296 9y ago
    Microsoft spends millions for backward compatibility and they charge a fortune for that. This is an open source project with not as much resources and the core protocol of X was never made for GUI. It was made for displaying a cute clock on the screen when there was no concept of GUI. They extended it to do something it was never meant to do. Youtube talk about it: https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44