3 ms·
Yet the people who were working on Xorg decided to write wayland instead. Why? Because there was little more benefit to he had from the previous approach. Xorg
by ATsch 6y ago
Yet the people who were working on Xorg decided to write wayland instead. Why? Because there was little more benefit to he had from the previous approach. Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.
- quotemstr 6y ago> Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution. You do realize the the X11 server connection is also almost always a Unix socket, right? (ITYM "Unix socket", not "Unix pipe".) That's like showing out your spork and replacing it with a spork. > Yet the people who were working on Xorg decided to write wayland instead. My whole point is that they were wrong to do so, just like I think the GTK people are wrong to break ABI on GTK4.
- ATsch 6y agoA completely new solution was inevitable because there was nothing more that could be done with Xorg. All of the complexity that mattered had moved into the WM, Compositor or Client. It wasn't actually doing anything anymore.
- quotemstr 6y ago> A completely new solution was inevitable because there was nothing more that could be done with Xorg. I see no evidence behind this assertion. What specifically would have prevented the further evolution of Xorg? > All of the complexity that mattered had moved into the WM, Compositor or Client. Good. So that means that Xorg didn't have to change very much. All Xorg had to do is provide mechanism, not policy, and let WM, compositor, and client cooperate as they've been doing for decades. But instead the Xorg maintainers got bored and decided to make a big ball of mud with no separation of concerns.