I wonder when Debian, SuSE, et al will do this too. XWayland will probably still sit around for a very long time even beyond that point though. Time will tell

I wonder when Debian, SuSE, et al will do this too. XWayland will probably still sit around for a very long time even beyond that point though. Time will tell how hilariously it gets integrated. I'm especially glad the video driver situation means X will hang around for a long time. I'm currently learning the X wire protocol and what I find the nicest about it is its eminent hackability. Wayland, on the other hand, is just a compositor. Seems comparatively boring, from the perspective I have (as an outsider who has dubiously picked through some poorly written documentation that doesn't inspire much confidence). Compositing chews more (system!) RAM, too; an X client doesn't need to allocate any memory of its own, only the X server holds the actual image of the window in memory (GPU memory obviously, and if you're using compositing, main memory as well). Yes, X has a thousand bugs. Yes, it would fall down a hundred times a second if it were actually possible to feed it into afl. Yes, I had it deadlock on my laptop (when running a program through xtruss and xterm tried to print too fast). Yes, I'm still yet to enable XF86Ungrab (introduced in 2010: https://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a3cb3089241982ce4f8984fd723d5312a1 https://cgit.freedesktop.org/xorg/xserver/commit/?id=7d2543a...) so I can fix broken grabs (at least the most recent one that happened this morning - when NFS momentarily timed-out right bang in the middle of me clicking in a menu bar and the menu [window] actually opening). Yes, XKB needed an XKB2, and then XI, and then XI2, because nobody thought we would need more than 256 individual input buttons (mice sometimes eat 30 keys from X's perspective...). DRI needed a DRI2 and then DRI3. Yes, Xinerama is actually named PanoramiX and not even used anymore thanks to RandR 1.2 ("RandR 1.2 enabled, ignore the following RandR disabled message." ... "RandR disabled"). And that's not even mentioning XFIXES and XC-MISC... About 4-5 days after starting on poking the X protocol specification for the first time, I crashed into https://bugs.freedesktop.org/show_bug.cgi?id=107568 https://bugs.freedesktop.org/show_bug.cgi?id=107568, which was highly amusing. I think that's been in there for 27 years. Not sure whether to call it a leaky abstraction or a case of "someone forgot their mechanism-over-policy hat that day", or both. But anyway. Not a critical bug, but a good illustration of poorly thought through design and implementation. I'm sad to see X die. Not from the it's-so-terrible standpoint; from that view, sure, yeah. But nostalgically speaking, it's older than I am :) and I guess it's sad to see things move on after having existed the way they are for so long (it's {h,cl}ung on for 30 years). I know, I know, it'll exist as a legacy component for the next 20 years. But that isn't the same as "nobody uses Perl but it's always installed anyway because some random init-time thing might call it." You can't just "call X". Having X floating around in the form of Xwayland is very similar to XQuartz; as a legacy component, I can see a status quo developing where the integration is subpar, but the situation isn't annoying enough for the people with the "social commit bits" to be insufficiently annoyed to fix it. Hopefully the integration is well-designed and keeps up with the times, at least on 2D screens with keyboards and mice. I wonder where Wayland will be in 15 years. Same for X. It'll be interesting. As an OS evaluator, I just wish Linux would stay still. Design things properly the first time (and actually put the time and effort in)! Hopefully Wayland doesn't have to change anything major for at least 20 years. (Why do I cynically expect it to have a tangle of circular dependencies on systemd and dbus within 10. :/) As a power user/sysadmin, I am _not_ looking forward to having to fuss around with Wayland and get it working. (I mean working _properly_.) As an end user, I hope I don't actually have to put my sysadmin hat on at all. As an inveterate tinkerer who likes hacking things in the true sense (finding interesting ways to reuse things :D), I'm sad because X is fun to figure out. (Try it.) From the perspective of a UX designer who likes building efficient integrated software, I have to sadly reiterate a comment I made 2 years ago (before I accidentally locked 'i336_): https://news.ycombinator.com/item?id=13334053 https://news.ycombinator.com/item?id=13334053 > I'm really sad X11 is legacy software myself, as an aside. It's a disaster, sure, but now we have one more layer of "uhhhh..." for all the UX-types to get scared away by: it used to be "(WinAPI) vs ((Qt)/(GTK+)/(Xlib/XCB))", which was embarrassing enough; now it's "(WinAPI) vs (X11((Qt)/(GTK+)/(Xlib/XCB))/Wayland((Qt)/(GTK+)/(???)))" which is just plain annoying for low-level graphics hacker wannabes - I can make a WinAPI app in C that opens a window in a few KB, where as to do that in Linux now I HAVE to support XCB and also write my own tiny UI for Wayland. I guess this is the major point of my tired rant: I wish I could wet-fish all of Linux and yell something along the lines of "stop increasing the surface area developers must target!!!! Backward compatibility is not developer responsibility!!", but I can't, because Linux is a bazaar, and everyone is too busy trying to compete for the most amount of responsibility they can elegantly juggle.