I’m curious how software can be created and evolve over time. I’m afraid that at some point, we’ll realize there are issues with the software we’re using that can only be remedied by massive changes or a complete rewrite.
Are there any instances of this happening? Where something is designed with a flaw that doesn’t get realized until much later, necessitating scrapping the whole thing and starting from scratch?
Seriously, I’m not a heavy software developer that partakes in projects of that scale nor complexity but just seeing it from the outside makes me hurt. All these protocols left-right and center, surely just an actual program would be cleaner? Like they just rewrite X from scratch implementing and supporting all modern technology and using a monolithic model.
Then small projects could still survive since making a compositor would almost be trivial, no need to rewrite Wayland from scratch cause we got “Waykit” (fictional name I just thought of for this X rewrite), just import that into your project and use the API.
What was stopping X just undergoing some gutting? I get it’s old and covered in dust and cobwebs but look, those can be cleaned off.
“Scoop out the tumors, and put some science stuff in ya”, the company that produced that quote went on to develop the most advanced AGI in the world and macro-scale portable on-demand indestructible teleportation.
No body wanted Wayland except the mad scientists and anti nvidia bigots that made it.
That would work if the only problem they wanted to solve was an outdated tech stack for X. But there are other problems that wayland addresses too, like: how to scale multiple monitors nicely, is it a good idea to give all other apps the keystrokes that you do in the one in focus (and probably a lot more)
I agree in the sense that Wayland adoption would have definitely gone quicker if that was the case, however in the long run this approach does make sense (otherwise you will eventually just run into the same sorts of issues X11 had).
Btw what you’re describing is not that far off from the normal way of using Wayland protocols in development - you use wayland-scanner to generate C source files from the protocols, and you include those to actually “use” the protocols in your programs. Admittedly all my Wayland development experience has been “client-side”, so I really don’t know how complex it is to build a compositor, but dwl (minimalist Wayland compositor) is only around 3k lines of code (only slightly more than dwm (minimalist X wm)).
Wayland and X are very very different. The X protocol is a protocol that was designed for computer terminals that connected into a mainframe. It was never designed for advanced graphics and the result is that we have just built up a entire system that balances on a shoe box.
Wayland is a protocol that allows your desktop to talk to the display without a heavy server. The result is better battery life, simplified inputs, lower latency, better performance and so on
It is complex to build a Wayland compositor. When none existed, you had to build your own. So it took quite a while for even big projects like GNOME and KDE to work through it.
At this stage, there are already options to build a compositor using a library where most of the hard stuff is done for you.
https://github.com/swaywm/wlroots
https://github.com/CuarzoSoftware/Louvre
There will be more. It will not be long before creating Wayland compositors is easy, even for small projects.
As more and more compositors appear, it will also become more common just to fork an existing compositor and innovate on top.
One of the longer term benefits of the Wayland approach is that the truly ambitious projects have the freedom to take on more of the stack and innovate more completely. There will almost certainly be more innovation under Wayland.
All of this ecosystem stuff takes time. We are getting there. Wayland will be the daily desktop for pretty much all Linux users ( by percentage ) by the end of this year. In terms of new and exciting stuff, things should be getting pretty interesting in the next two years.
