This is starting to feel like the arguments against systemd all over again. A few highly vocal people hate it, but it works just fine for almost everybody else.
At this point I cannot actually replicate Xfce feature-for-feature in Wayland, not without inventing private protocols of my own, which I'd prefer not to do. My biggest issue right now is xfce4-panel, and embedding surfaces from one process into a parent process. There's no Wayland way to do this, and the Wayland folks have explicitly rejected some sort of XEMBED-workalike Wayland protocol, instead telling people they should write an embedded Wayland compositor. Well, I've been working on that for the past eight months, and it's hard to get right. I have something that "works", but it has a lot of rough edges, and, critically, eventually either the parent app or embedded apps run into weird spurious protocol errors and quit. While yes, that's technically my fault and my bugs, working with an under-documented protocol and really bare-bones libraries for building apps (wlroots, sadly, is not suitable for writing an embedded compositor, as it does too much) doesn't make any of this easier. I've written more than 10k lines of code (so far), and, meanwhile, you can do an XEMBED implementation in a few hundred.
I get that X11 made certain things impossible. But why not build an "X12" rather than throwing everything out and staring completely from scratch? It seems like people just didn't feel like it, and building something new was more exciting and would look better on their resume. I of all people know it's not cool to tell people what open source software to build in their spare time (though, to be fair, many/most of the people involved in Wayland are employed or at least funded by corporations), but jeez, this has been exhausting.
Those people were largely the Xorg developers. They knew what they were up against and clearly decided this was a better idea.
They may have overcorrected, but they’ve been fixing things compared to the early releases.
Wayland is here, it works (for a great many things), and it’s under active development to keep improving.
Xorg is not.
With the world moving ever more again towards distributed computing (Like Windows desktop in the cloud which you can rent now from Microsoft) it would be amazing if each window on my computer could run on a different physical computer. I could run my 3D Design program on a heavy instance somewhere, my browser on a medium instance (and sandboxed), and some smaller programs locally. X11 can do all that today (and it could in 1995!) but it's not very good at it due to the latency sensitivity introduced by the many roundtrips in the protocol. Wayland can't because it's really designed to be fully local.
I think, if I was going to consider and "X12" though, what I think would be the steps to start with would to trim the starting point down aggressively, to reduce the maintenance burden:
* "Promote" certain extensions, like BigRequests and XRender and enable them automatically.
* XRender requires a fixed set of visuals, including 24 bit and 32 bit. As a result, if you require XRender you can reasonably aggressively deprecate most inferior visuals. You might lose some old software without shims/a proxy that way. But frankly I don't think it's worth caring enough - if any of it is worth keeping, a shim is fine.
* Aggressively deprecate most legacy rendering calls and options. Almost all of it can trivially be shimmed client side or supported via a proxy if any extant/in use apps still support them. This includes support for server-side bitmap fonts (they can trivially be supported by XRender glyph support).
* Remove most backends. Support maybe one "dumb"/basic backend for legacy use, but remove as much possible.
The point is you can do a vastly better job if you strip the thing bare first.
Not gonna do it. Wouldn't be prudent at this juncture.
https://www.youtube.com/watch?v=4QHHGHve_N0
X-Windows Disaster:
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
I think the biggest challenge today is that people would be more likely to just use a web browser for most of those things that would benefit most from working over the network, and latency for locally run software isn't a big deal (my wm, which I've mentioned elsewhere, is written in Ruby and spews about a dozen lines of debug output to the terminal for every mouse move during resize and drag at the moment, and yet it's smooth enough).
It'd be fun to try, though.
[EDIT: One simple/fun idea as a starting point for something like that would be to simply add an extension that injects such a wasm binary as a "filter" between inbound requests and outbound events/replies]
and I'm seeing many of the same kind of arguments as with systemd
like arguments you could re-formulate as "but my kinda uncommon setup which is irrelevant for the maintainers and sponsors of which do the decision will not work and it's bad to not support everyone for free" or "but you can't to X in that specific way and because of that you can't do so at all (ignoring alternative ways) and because of that it can't replace it at all" or "hung up on some technical detail which doesn't matter for 99% of users" or "my software which wasn't properly updated since 10 years doesn't work flawless under Wayland" or "hung up on something which wasn't supported initially but is supported since multiple years by now"
in the end someone will probably continue to support Xorg and someone will probably maintain it and it probably will get increasingly more painful to run it but it also will take many years until it really hurts and it probably will be banned from most companies caring about security and people starting to use Linux in some years in the future will probably not really know what Xorg is except is that thing related to some ancient programs not behaving nicely and they will wonder what it has to do with X(Twitter) and if thats why it's no longer used.
I'm sure I can make do with systemd but I don't like it, and thus I chose an OS that doesn't use it. I also don't like the way it was orchestrated that I don't have a choice. I want choices. And I don't like my system changing for the sake of it.
But with RedHat positioning themselves as the center of the Linux world it is quite difficult to avoid their stuff. They still have a huge finger in the pie and people still respect them as if IBM hadn't taken them over. Even after CentOS where people are even supporting their narrative of "freeloaders" when it comes to Alma and Rocky Linux.
I really hope some org from perhaps the BSDs will take over maintainership of Xorg instead of allowing RedHat to shutter it. Choice is good.
Nostalgia for X-Windows is just as naive. Since nobody even uses X-Windows networking any more, they'd be better off with SunView.
X-Windows is only free if your time is worthless.
And that even drives me to write more X code because looking into whether I could realistically do the same upgrades to my environment with Wayland has put me off every time (I could write a tiny wm or be forced to maintain my own compositor - even the "tinywl" wlroots example is several times the size of my current wm, while not doing what I want).
For me it is purely pragmatic. If/when it gets harder to keep my X setup running than migrating, I'll migrate, and I do what I can't to keep the X-specific parts of my code well isolated. But it's likely to take many years before migrating becomes easier than staying put at this rate - frankly, odds are what will make me migrate is if/when the browsers drop X support.
I use the simple but functional BSD stuff :)
> Since nobody even uses X-Windows networking any more
I still use it every day
% ls -lh =craicwm
-rwxr-xr-x 1 root root 1.2M Sep 17 2019 /usr/bin/craicwm*
"I use my home-grown WM" is an uncommon scenario, but "I have some specific thing written for X" isn't (this is just a bit of an extreme variant of that), and neither is "I'm rather used to my current setup, and I'd rather not change". I have a bunch of other programs that have no clear alternative; I've written some myself, some are by others. Perhaps my favourite is my wm-scratch[1] script to quickly show/hide a "scratch terminal" or other windows like Firefox devtools. I will need to re-create all of that. I don't even know if something like wm-scratch is possible under Wayland (maybe, maybe not?)
I know very few people who like X11 as such. In fact, I know no one who does, and never have. I do know a lot of people for whom X11 works "good enough", and don't feel like spending time changing things.
If this is a new argument for you then you really haven't been listening, because this is what many people have been saying for years.
As for systemd, my argument has always been "SysV init sucks, but so does systemd, and we have much better systems like daemontools". "SysV init sucks, so therefore systemd is the only possible answer" has always been one of the great fallacies of that entire discussion.
[1]: https://github.com/arp242/dotfiles/blob/master/local/script/...