6 ms·

Would addressing the "firewalling" issue be more disruptive than throwing out X11? Because, Wayland definitely firewalls programs (among many other things) --

by jude- 6y ago

Would addressing the "firewalling" issue be more disruptive than throwing out X11? Because, Wayland definitely firewalls programs (among many other things) -- surely just implementing firewalling in X11 is not nearly as difficult or disruptive? Implementing firewalling could even be done in an incremental way that's easily reverted or tailored to individual apps and users.

tux1968 6y ago
I'm no expert in the X11 codebase, but I have lots of respect for the guys who were working on it at the time the Wayland direction was undertaken. So I don't feel in a position to second guess their opinion or tremendous contributions, especially since it has led to a much better experience than I ever had with X.
- jude- 6y ago
  That doesn't make them infallible. If anything, Wayland smells like yet another instance of CADT [1]. Like, why can no one explain why a world-breaking change like Wayland is justified, when the problems Wayland solves seem like they could be addressed by repairing X11? I'm honestly interested in building a better X11, and am willing to contribute both time and money. But first, I'd like to understand why the X11 maintainers deemed Wayland necessary -- like, what am I missing here? [1] https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
  - cycloptic 6y ago
    The main problems with X11 are within the core X11 protocol itself, things that are long considered deprecated/obsolete and can't be fixed or removed without doing a protocol break. I could go more into detail, but if you depend on some old X clients that use all those old protocol features, and you're already committed to putting money down on X11, it seems unlikely that those details would be relevant to you. Please let me know if I'm reading this wrong here. I support you working on X11, but just be warned, it is highly unlikely that the major desktops are going to want to continue on that path going forward.
    - jude- 6y ago
      > The main problems with X11 are within the core X11 protocol itself, things that are long considered deprecated/obsolete and can't be fixed or removed without doing a protocol break. Which problems, exactly, would these be? Why is it impossible (or too difficult or disruptive) to solve these problems through a server extension, or some other backwards-compatible fix? I'm sure the X.org developers have an answer, but I'm not seeing it here. > it is highly unlikely that the major desktops are going to want to continue on that path going forward. I don't care what other desktops and toolkits choose to do -- I don't even use a fd.o desktop (hell, I don't even run dbus). If it weren't for needing a Web browser and Zoom, I wouldn't even need a GUI at all. I'm doing this for myself. I like UNIX a lot, but I really dislike the direction modern Linux desktops are going in. But instead of whining about it online, I'm willing to put in the time and effort to keep things working the way I like. I'm asking what problems Wayland solves in order to figure out why it's a bad idea for me to take a crack at implementing a simple X server of my own (assuming X.org is indeed going to be deprecated). Like, what is so wrong/broken about the X11 protocol that the X.org server developers are so enthusiastic about abandoning it? Clearly, I must be missing something. I would like to know what that something is.
      - cycloptic 6y ago
        You really should consider watching the youtube talk that was linked in some sibling comments, it explains it in more detail than I could in just one post. For me personally, the real bad issues are things like the core protocol being synchronous, the coordinates being limited to 16-bit, the inherent raciness and insecurity of various things like window properties and server grabs... There is a lot of legacy functionality there too like colormaps, window borders, bitmap fonts, all the core drawing primitives, all the core input stuff.... Newer applications are not using any of that, and often with that legacy stuff the the only specified behavior for edge cases that clients expects is "do whatever Xorg does" which makes a rewrite pretty impractical. It would be interesting to see a secure rewrite of the X server in Rust or some newer language like that, but doing that would probably take many years for little benefit, I'd advise against it. Side note, I don't get the hate for dbus, it's a rather simplistic message bus, orders of magnitude smaller than the X server. It would be much easier to implement your own dbus daemon for example.
  - tux1968 6y ago
    I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very architecture it was designed around was becoming moot since things were shifting to client side rendering already. Couldn't find a good article on short notice, but there's a decent video from back in 2013 about it. https://youtu.be/cQoQE_HDG8g https://youtu.be/cQoQE_HDG8g
    - jude- 6y ago
      > I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very architecture it was designed around was becoming moot since things were shifting to client side rendering already. I can totally get behind doing a clean re-write of X.org (possibly in a memory-safe language this time around) in order to get rid of legacy cruft that's truly no longer used. They could take the opportunity to refactor the super-popular X extensions like GLX to have better "happy paths" in order to make the overall implementation cleaner and easier to maintain. This could even be done incrementally in order to avoid breaking existing clients. What I'm struggling to understand is what's so wrong with X11-the-protocol and the popular extensions that ditching everything was considered the best idea? Like, if the X11-to-Wayland transition were happening on the Web, it would be a lot like Google deciding to ditch HTML/CSS/Javascript in favor of something home-grown. Sure, that homegrown thing might actually be better, but it would really leave everyone else in a real lurch now, wouldn't it?
      - tux1968 6y ago
        Well there were a lot of problems with the X protocol actually, having to do with latency and multi-threading support at the very least. So much so that Xcb was developed as a replacement protocol; so applications were already having to be refactored if they wanted to avoid such problems. But really, most applications do not deal with Xlib or Xcb _anyway_, they are programmed at the Gui toolkit level. So all that has to be done is add another backend to the few popular toolkits in use. But guess what, Wayland supports both Xcb and Xlib protocols through a virtual X server that transparently translates to Wayland if that's what you have your heart set on. But I have lost track of what the specific problem is you're actually trying to solve.
kaba0 6y ago
I can’t reply to your comment below this, but the Wayland guys are the X guys, and while they are definitely not infallible, don’t you think it is a bit egoistic to think that they didn’t thought of this one simple little thing that you did, without any knowledge on the inner workings of any display server? I’m sorry if it sounds harsh, but honestly.
- jude- 6y ago
  Don't get me wrong, I'm not trying to suggest that the X devs are ignorant of this. I too have both deep respect and gratitude for the work they have done and continue to do. I'm only frustrated that I can't get a straight answer as to what problems Wayland is solving that can't be solved with less difficulty and breakage by repairing X11. I'm sure the X.org developers have an answer, and I would love to know it, but I'm not getting it here in this comment tree.
  - kaba0 6y ago
    Here you are: https://youtu.be/cQoQE_HDG8g https://youtu.be/cQoQE_HDG8g It’s a great presentation by one of the guys behind wayland, who worked on X a lot before. Basically, X has a fundamentally misaligned abstraction of the underlying hardware - which is expected based on its age. When used with a compositor, it is basically a middle-man with no function whatsoever. So Wayland decided to cut out the middle man and pass events directly between client and compositor. But please watch the video, I think it will answer all your questions. Also, it’s not like X will be totally deprecated, XWayland is an API implementation of it that will be supported forever.
    - jude- 6y ago
      Right, and as I said elsewhere, this is a problem with the reference implementation being crusty, not X11. That seems to be the point the speaker is making as well. Like, I'm fully supportive of having the X server simply manage DRI3 for a bunch of clients and composite the results. That's all well and good. I'm less supportive of doing this while also removing all support for the other things that the X server provides the ecosystem: * Unified input/event capturing and forwarding * Unified screen capturing/recording * Window management * Clipboard * Structured IPC (on top of which you get ICCCM and NetWM) * Xrdb * Xprops * Notions of windows in general (everything's now client-side) * Fonts * Drawing APIs These were all standardized things that users could count on always being available, regardless of which GUI programs they used. Wayland completely punts on these things and defers them to extensions. Before you ask, I've already seen the "Wayland is a protocol; these are all extensions" song and dance routine. That's a cop-out. Dropping these things means that there will now be multiple incompatible implementations of the same concept, and no way to mix-and-match them because they now all have to be built into the same process that does your window management. Wayland implementations completely destroy this digital commons, for no apparent reason or gain for the users. The only people I see potentially benefiting from this are full-fledged DEs who can leverage their compositors' incompatible implementations to enact a form of lock-in (i.e. your GNOME programs are no longer guaranteed to run in KDE, and vice versa). So, why do this?

by jude- 6y ago

tux1968 6y ago

I'm no expert in the X11 codebase, but I have lots of respect for the guys who were working on it at the time the Wayland direction was undertaken. So I don't feel in a position to second guess their opinion or tremendous contributions, especially since it has led to a much better experience than I ever had with X.

jude- 6y ago
That doesn't make them infallible. If anything, Wayland smells like yet another instance of CADT [1]. Like, why can no one explain why a world-breaking change like Wayland is justified, when the problems Wayland solves seem like they could be addressed by repairing X11? I'm honestly interested in building a better X11, and am willing to contribute both time and money. But first, I'd like to understand why the X11 maintainers deemed Wayland necessary -- like, what am I missing here? [1] https://www.jwz.org/doc/cadt.html https://www.jwz.org/doc/cadt.html
- cycloptic 6y ago
  The main problems with X11 are within the core X11 protocol itself, things that are long considered deprecated/obsolete and can't be fixed or removed without doing a protocol break. I could go more into detail, but if you depend on some old X clients that use all those old protocol features, and you're already committed to putting money down on X11, it seems unlikely that those details would be relevant to you. Please let me know if I'm reading this wrong here. I support you working on X11, but just be warned, it is highly unlikely that the major desktops are going to want to continue on that path going forward.
  - jude- 6y ago
    > The main problems with X11 are within the core X11 protocol itself, things that are long considered deprecated/obsolete and can't be fixed or removed without doing a protocol break. Which problems, exactly, would these be? Why is it impossible (or too difficult or disruptive) to solve these problems through a server extension, or some other backwards-compatible fix? I'm sure the X.org developers have an answer, but I'm not seeing it here. > it is highly unlikely that the major desktops are going to want to continue on that path going forward. I don't care what other desktops and toolkits choose to do -- I don't even use a fd.o desktop (hell, I don't even run dbus). If it weren't for needing a Web browser and Zoom, I wouldn't even need a GUI at all. I'm doing this for myself. I like UNIX a lot, but I really dislike the direction modern Linux desktops are going in. But instead of whining about it online, I'm willing to put in the time and effort to keep things working the way I like. I'm asking what problems Wayland solves in order to figure out why it's a bad idea for me to take a crack at implementing a simple X server of my own (assuming X.org is indeed going to be deprecated). Like, what is so wrong/broken about the X11 protocol that the X.org server developers are so enthusiastic about abandoning it? Clearly, I must be missing something. I would like to know what that something is.
    - cycloptic 6y ago
      You really should consider watching the youtube talk that was linked in some sibling comments, it explains it in more detail than I could in just one post. For me personally, the real bad issues are things like the core protocol being synchronous, the coordinates being limited to 16-bit, the inherent raciness and insecurity of various things like window properties and server grabs... There is a lot of legacy functionality there too like colormaps, window borders, bitmap fonts, all the core drawing primitives, all the core input stuff.... Newer applications are not using any of that, and often with that legacy stuff the the only specified behavior for edge cases that clients expects is "do whatever Xorg does" which makes a rewrite pretty impractical. It would be interesting to see a secure rewrite of the X server in Rust or some newer language like that, but doing that would probably take many years for little benefit, I'd advise against it. Side note, I don't get the hate for dbus, it's a rather simplistic message bus, orders of magnitude smaller than the X server. It would be much easier to implement your own dbus daemon for example.
- tux1968 6y ago
  I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very architecture it was designed around was becoming moot since things were shifting to client side rendering already. Couldn't find a good article on short notice, but there's a decent video from back in 2013 about it. https://youtu.be/cQoQE_HDG8g https://youtu.be/cQoQE_HDG8g
  - jude- 6y ago
    > I tried to give a hint about the basic reason of trying to get out from under the weight of a huge code base that had become old and crufty while the very architecture it was designed around was becoming moot since things were shifting to client side rendering already. I can totally get behind doing a clean re-write of X.org (possibly in a memory-safe language this time around) in order to get rid of legacy cruft that's truly no longer used. They could take the opportunity to refactor the super-popular X extensions like GLX to have better "happy paths" in order to make the overall implementation cleaner and easier to maintain. This could even be done incrementally in order to avoid breaking existing clients. What I'm struggling to understand is what's so wrong with X11-the-protocol and the popular extensions that ditching everything was considered the best idea? Like, if the X11-to-Wayland transition were happening on the Web, it would be a lot like Google deciding to ditch HTML/CSS/Javascript in favor of something home-grown. Sure, that homegrown thing might actually be better, but it would really leave everyone else in a real lurch now, wouldn't it?
    - tux1968 6y ago
      Well there were a lot of problems with the X protocol actually, having to do with latency and multi-threading support at the very least. So much so that Xcb was developed as a replacement protocol; so applications were already having to be refactored if they wanted to avoid such problems. But really, most applications do not deal with Xlib or Xcb _anyway_, they are programmed at the Gui toolkit level. So all that has to be done is add another backend to the few popular toolkits in use. But guess what, Wayland supports both Xcb and Xlib protocols through a virtual X server that transparently translates to Wayland if that's what you have your heart set on. But I have lost track of what the specific problem is you're actually trying to solve.

kaba0 6y ago

I can’t reply to your comment below this, but the Wayland guys are the X guys, and while they are definitely not infallible, don’t you think it is a bit egoistic to think that they didn’t thought of this one simple little thing that you did, without any knowledge on the inner workings of any display server? I’m sorry if it sounds harsh, but honestly.

jude- 6y ago
Don't get me wrong, I'm not trying to suggest that the X devs are ignorant of this. I too have both deep respect and gratitude for the work they have done and continue to do. I'm only frustrated that I can't get a straight answer as to what problems Wayland is solving that can't be solved with less difficulty and breakage by repairing X11. I'm sure the X.org developers have an answer, and I would love to know it, but I'm not getting it here in this comment tree.
- kaba0 6y ago
  Here you are: https://youtu.be/cQoQE_HDG8g https://youtu.be/cQoQE_HDG8g It’s a great presentation by one of the guys behind wayland, who worked on X a lot before. Basically, X has a fundamentally misaligned abstraction of the underlying hardware - which is expected based on its age. When used with a compositor, it is basically a middle-man with no function whatsoever. So Wayland decided to cut out the middle man and pass events directly between client and compositor. But please watch the video, I think it will answer all your questions. Also, it’s not like X will be totally deprecated, XWayland is an API implementation of it that will be supported forever.
  - jude- 6y ago
    Right, and as I said elsewhere, this is a problem with the reference implementation being crusty, not X11. That seems to be the point the speaker is making as well. Like, I'm fully supportive of having the X server simply manage DRI3 for a bunch of clients and composite the results. That's all well and good. I'm less supportive of doing this while also removing all support for the other things that the X server provides the ecosystem: * Unified input/event capturing and forwarding * Unified screen capturing/recording * Window management * Clipboard * Structured IPC (on top of which you get ICCCM and NetWM) * Xrdb * Xprops * Notions of windows in general (everything's now client-side) * Fonts * Drawing APIs These were all standardized things that users could count on always being available, regardless of which GUI programs they used. Wayland completely punts on these things and defers them to extensions. Before you ask, I've already seen the "Wayland is a protocol; these are all extensions" song and dance routine. That's a cop-out. Dropping these things means that there will now be multiple incompatible implementations of the same concept, and no way to mix-and-match them because they now all have to be built into the same process that does your window management. Wayland implementations completely destroy this digital commons, for no apparent reason or gain for the users. The only people I see potentially benefiting from this are full-fledged DEs who can leverage their compositors' incompatible implementations to enact a form of lock-in (i.e. your GNOME programs are no longer guaranteed to run in KDE, and vice versa). So, why do this?