First off, a 45 minute long video isn't much of a citation. Where, exactly, are you citing?
Secondly, this isn't the first time I've had people point to this same video. It doesn't actually say what you claim it says. It says the creator of Wayland worked on X (though actually his core focus was DRI2, which btw, is not X), and the one individual speaker in that video worked on X a long time ago (specifically his focus was on keyboard input).
Their claim is more "X is redundant" than "X is hopeless". They're wrong, of course, the video makes absurd claims like "nobody uses core X11". Maybe they don't since they work in niches, but in the real world, plenty of people do... and that's the part of the X server nobody actually complains about. Even Wayland are perfectly OK with that part! (See retaining it in XWayland. When these wayland devs complain about Xorg their focus is usually on the driver side. Well, hate to break it to them, drivers are always ugly. See the link we're commenting on, if Wayland actually works on all the devices Xorg works on, it'll be just as ugly.)
How about the actual technical details in the video? With a compositor on top of X, what purpose does X actually serve other than being an unnecessary complicated IPC layer that duplicates many of the messages?
Also, there have been another HN post with “X is abadonware” or similarly titled, which was written by another X maintainer. But feel free to check the mailing list as well looking at activity.
I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
But even if you do, the compositor only does one job: layer graphics. Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. Wayland either fragments this (saying it is all the compositor's problem or punts it to dbus or something), or ignores it (they feel about useful things the way I feel about compositors), and will likely reinvent it eventually anyway.
And btw, what about X is unnecessarily complicated? I love the way the presenter claims the specs are impossible but I managed to implement them and so did a bunch of other people. So apparently it isn't actually that hard. and btw they aren't actually all that different than similar functionality in different operating systems, aside from things like asynchronous chunking... which is a good thing, since you don't want to block your UI event loop anyway! So it is what good programs ought to be already doing.
> I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless.
Have you tried watching a video in full screen?
> But even if you do, the compositor only does one job: layer graphics
Yes, and this small little detail is not solved by X, but Wayland.
> Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc.
And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it.
> I love the way the presenter claims the specs are impossible but I managed to implement them
What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere.
And I’m not sure what you mean by asynchronous chunking. You mean tearing?
You do have to synchronize somewhere.
Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway?
You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy.
The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker.
> X’s APIs are globally broadcasted
No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it.
> What part of it?
Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server.
And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works.
That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc.
(Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!)
wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)
Well, I can continue on listing problems with X. How about HDPI? Or mixed HDPI? I’m sure some things can be retrofitted, but I still don’t see why should we continue with a protocol not planned for/with modern hardware in mind.
Also, regarding network transparency. As you note, most apps are no longer network transparent, and remote window streaming can be much better solved with modern compressions/encoding. It doesn’t have to be part of the core protocol, the latter should only concern itself with displaying rectangles on the screen. Everything else can be built on top of it.
Also, while in itself not a good argument, both MacOS and windows use a compositor since forever.
