Wayland + spice seems like a decent option for remote graphics support, but I'm unsure if spice supports remoting individual apps, rather than full desktop sessions.

I'm pretty sure Xorg isn't going to stop building, and I'd doubt that things like Gtk are going to throw away their X11 backend, so you can continue to live in 1983 where you are happy :)

spice doesn't today, but that doesn't mean it can't or won't.

but for ltsp, spice is far better than straight X.

Assuming that this is the Spice you mean, it may be better than LTSPs at some point in the future but right now it's useful for this at all, as I can't see any way to run an X server that uses the Spice protocol as its display so that you can provide an X desktop directly to a Spice client. (Well, a Gnome or a KDE desktop, mostly.)

(We have no interest in providing a separate virtual machine to every LTSP user.)

On the 'things not stopping building' issue:

On a pragmatic basis I don't expect either Linux distributions or large programs and libraries to really support both Wayland and X for very long, regardless of what they claim. It is just too much work to code for, test, qualify, and maintain a duplicate set of graphical environments, to make sure that Gnome and KDE and Firefox and Thunderbird and Gtk and this and that work well in both Wayland and X. Pretty soon X will become a second class citizen and then fall into a state where it is officially unsupported and in practice increasingly broken.

Well before that point you have no practical alternative but to migrate, because all of the new development is happening for one and all of the environment starts assuming features that only exist on one.

(This is what you should expect. Wayland's ability to things better than X and to do things that X can't do is exactly why people want to migrate to it; why should they ignore all of those Wayland only features and thus effectively ignore Wayland's benefits? If they're going to do that, there's no point to pouring resources into Wayland at all.)

This exact pattern has been seen with all sorts of libraries and code over the years, so I don't expect X/Wayland to be any different. Nor, it seems, do the X developers; in the linked articles, I haven't seen anyone claim that they are going to try to maintain the two in parallel and at feature parity.

Sure, eventually you'll probably have to stop using fvwm, but is that really terribly surprising? 17 years is pretty damn good for a codebase and I if you consider the support life of enterprise linux distros, if new releases broke fvwm tomorrow you're still good for most of the next decade.

I would expect that GTK+ et al will have X11 backends maintained by non-Linux parts of the community; there will (presumably) be some incentive for Solaris, *BSD, etc types to maintain the X11 functionality.

Me too, I am still living in 1985, and why? First because fvwm is the only one wm that provide me with a decent mouse focus policy, and secondly because fvwm can do more than any other wm. Fvwm is not only a wm, it is a toolkit at the same time.

Last but not least, I think they missed a point with wayland. They want more speed and integration, but they didn't integrated the toolkit into the wm. If I look at Aros, a free implementation of the Amiga OS, that can run natively, or hosted on a GNU/Linux distribution, the toolkit is integrated into the wm, which is integrated into the graphic server. And yes, unlike the original Amiga OS, Aros do provide an hardware abstraction layer, even if it is a lack of drivers at that time.

The result with an application like gimp is that the hosted Aros version is starting at least 5 times faster than the native gentoo version. But of course, the QT and GTK folks will not like such a move in the right direction :)

To the question what will be my next box, I have no definitive answer at that time, but I am looking for alternatives because the problem with GNU/linux now is not limited to wayland. A thing like polkit is not only as idiotic than Gnome, it is also a real screwware.tm. In general, a lot of peoples are thinking the never the better, which is the main dogma of the commercial OS like wondows or mac. Take pulse audio, you can do the same and more with jack and the snd-aloop ALSA module, but with something that pa is unable to provide, a constant sound latency, something which is a must for any serious audio work. So what is best, the old jack audio connection kit or the never pulse audio?

To the question what will be my next box? I don't like windows or mac, and I prefer real games over their substitutes, so it will maybe be a card game or a domino.

Dominique Michel, Fvwm-Crystal administrator and developer

I think that integrating the toolkit into the window manager and the graphical server is something that time has demonstrated to actually be a mistake. The short version of why is that it's much easier for a separate toolkit instance in every client to take advantage of multiple-CPU systems.

(You can make a single display server or WM be multi-threaded, but multi-threaded programming is harder than 'independent process' programming. The latter gives you parallelism basically for free and the OS can do a lot of interesting things with scheduling priority for you.)