4 ms·

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 do

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.
  - jude- 6y ago
    From what I got from the video, the main complaint is that the X.org reference implementation has gotten really crusty and hard to maintain. If so, maybe the solution there would be to do some housekeeping and start deprecating features no one uses. Maybe that could include factoring legacy/obscure protocols and code-paths into separate code modules, off the server's "happy paths," which these protocols' downstream consumers can take over maintaining (if they really still need them). This doesn't call for ditching X11 in my mind. > 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... Why can't an extension offer a way for clients to establish asynchronous communication channels to the X server? Why can't an extension offer 64-bit coordinates? Why can't an extension offer a way for an authorized program to take care of guarding and serializing access to window properties and orchestrating server grabs? Why do we need to break the world to have these things?!? These may not be trivial undertakings, but I doubt they would take anywhere close to the amount of work required to upgrade every graphical program and toolkit in UNIX-land to use a wholly-different _suite_ of input/video multiplexing systems (which on a given day will be only 95% compatible with one another in expectation). Also, it's not like Wayland is destined to be less crufty than X11. I wouldn't be surprised at all if all of the complexity in X.org today returns to Wayland compositors by way of a bunch of all-but-required Wayland extensions that get shoe-horned in over the years. So if we're going to be shoe-horning new features into existing systems, we might as well do it on the devil we all know (or perhaps we should solve this once and for all by creating an "X12" protocol in a way that shoe-horning is painless and won't lead us to cruftiness again). > 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. It's not simplistic for what it does, and its developers have a horribly-misguided "put-it-in-the-kernel-because-performance" development ideology that belies a profound lack of understanding of why or how dbus isn't fast enough for their purposes. My biggest turn-off is the fact that it doesn't do anything that I can't already do faster and cheaper with a RAM filesystem of named pipes and UNIX domain sockets. * Want user/system namespaced paths? Create a directory for each users' endpoints that's separate from other users' endpoints, and have a distinct system/ directory that only authorized users can explore. Leverage filesystem hierarchies and permissions to communicate which endpoints belong to the same service, and to control who can access them. * Want to register a service endpoint for suspending/shutting-down your laptop? Create a directory under system/ whose group ID is the group of users who are authorized suspend/shutdown, put two "suspend" and "shut-down" named pipes in them, and have a suspend/shutdown daemon just do blocking reads from them. Once a byte arrives on the "suspend" pipe, execute suspend-to-RAM. Once a byte arrives on the "shut-down" pipe, execute shutdown. * Want to register a service endpoint for sending desktop notifications? Make a "notifications" directory in the user's service endpoints directory, and put a UNIX domain socket in it. Have the notification daemon listen on this socket, and simply pop up a window whenever another program connects to it and sends a properly-structured message (note that that other program must have permission to traverse the service directory to access this UNIX domain socket to do so). * Want introspection on how to form that message? Have the daemon that implements the endpoint write out a symlink to its documentation in its service directory, which you can just `cat` or `more` to figure out how to talk to the service. * Want something really elaborate, like sending a video stream? Transfer a file descriptor to the service provider via the UDS and then pipe the audio/video data in that way. So, yeah -- dbus doesn't need to exist in order for us to have the things it offers.

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.
- jude- 6y ago
  From what I got from the video, the main complaint is that the X.org reference implementation has gotten really crusty and hard to maintain. If so, maybe the solution there would be to do some housekeeping and start deprecating features no one uses. Maybe that could include factoring legacy/obscure protocols and code-paths into separate code modules, off the server's "happy paths," which these protocols' downstream consumers can take over maintaining (if they really still need them). This doesn't call for ditching X11 in my mind. > 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... Why can't an extension offer a way for clients to establish asynchronous communication channels to the X server? Why can't an extension offer 64-bit coordinates? Why can't an extension offer a way for an authorized program to take care of guarding and serializing access to window properties and orchestrating server grabs? Why do we need to break the world to have these things?!? These may not be trivial undertakings, but I doubt they would take anywhere close to the amount of work required to upgrade every graphical program and toolkit in UNIX-land to use a wholly-different _suite_ of input/video multiplexing systems (which on a given day will be only 95% compatible with one another in expectation). Also, it's not like Wayland is destined to be less crufty than X11. I wouldn't be surprised at all if all of the complexity in X.org today returns to Wayland compositors by way of a bunch of all-but-required Wayland extensions that get shoe-horned in over the years. So if we're going to be shoe-horning new features into existing systems, we might as well do it on the devil we all know (or perhaps we should solve this once and for all by creating an "X12" protocol in a way that shoe-horning is painless and won't lead us to cruftiness again). > 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. It's not simplistic for what it does, and its developers have a horribly-misguided "put-it-in-the-kernel-because-performance" development ideology that belies a profound lack of understanding of why or how dbus isn't fast enough for their purposes. My biggest turn-off is the fact that it doesn't do anything that I can't already do faster and cheaper with a RAM filesystem of named pipes and UNIX domain sockets. * Want user/system namespaced paths? Create a directory for each users' endpoints that's separate from other users' endpoints, and have a distinct system/ directory that only authorized users can explore. Leverage filesystem hierarchies and permissions to communicate which endpoints belong to the same service, and to control who can access them. * Want to register a service endpoint for suspending/shutting-down your laptop? Create a directory under system/ whose group ID is the group of users who are authorized suspend/shutdown, put two "suspend" and "shut-down" named pipes in them, and have a suspend/shutdown daemon just do blocking reads from them. Once a byte arrives on the "suspend" pipe, execute suspend-to-RAM. Once a byte arrives on the "shut-down" pipe, execute shutdown. * Want to register a service endpoint for sending desktop notifications? Make a "notifications" directory in the user's service endpoints directory, and put a UNIX domain socket in it. Have the notification daemon listen on this socket, and simply pop up a window whenever another program connects to it and sends a properly-structured message (note that that other program must have permission to traverse the service directory to access this UNIX domain socket to do so). * Want introspection on how to form that message? Have the daemon that implements the endpoint write out a symlink to its documentation in its service directory, which you can just `cat` or `more` to figure out how to talk to the service. * Want something really elaborate, like sending a video stream? Transfer a file descriptor to the service provider via the UDS and then pipe the audio/video data in that way. So, yeah -- dbus doesn't need to exist in order for us to have the things it offers.