why X

A handful of reasons of why X is still relevant this day and
age; and what a replacement (if there will ever be one) will
need to have, or improve upon, to succeed.

Contains exaggerations, oversimplifications, and occasional
not-quite-verified information.  Corrections and constructive
criticism are of course welcome.


X is reasonably lightweight.

It's not a perfection given code, granted, but it still
remains one of the X competitive advantages.

First is the conceptual complexity.  The server manages the
hardware.  The clients connect to it and order things like
"draw a line here" or "put this text string over there."
It /is/ simple.

Sure, I can, and do, use framebuffer directly,

  $ gm convert -auto-orient -depth 8 \
        -background white -gravity center -resize 1280x1024 -extent 1280x1024 \
        -recolor "0 0 1 0, 0 1 0 0, 1 0 0 0, 0 0 0 1"  MYPIC.JPG rgba:/dev/fb0

Much like how I don't need a spooler to do printing,

  $ pdftocairo -png -singlefile -r 593 -f1 -l1 -- - - < MYDOC.PDF \
        | gm convert -auto-orient -colorspace Gray \
              -background white -gravity center \
              -resize 5100x6600 -extent 5100x6600 \
              -ordered-dither Intensity 3 \
        | foo2zjs -z1 -P -L0 -r600x600 -t -g5100x6600 -p9 > /dev/usb/lp0 &

But doing it like that, while /is/ simpler in one way, can
still be more complex in others.  It's a matter on where to
draw a line, and X draws its lines reasonably well.

Second is the protocol overhead.  As was pointed out in a
thread here (e. g., news:E4loZOuxDjnPBjUj@violet.siamics.net ),
QueryFont can be much improved with regards to 16-bit fonts;
otherwise, X has fairly low bandwidth requirements.

Finally, there's the amount of code involved, both overall
(affecting filesystem space requirements) and for specific
code paths (affecting performance and /predictability/ of
the behavior.)  For compatibility reasons, the former isn't
particularly good, and likely cannot be improved /without/
your own effort to tailor it down to your own needs.  The
latter so far has been looking good enough to me.

The end result is that if you want a windowing system that
you can hack in your spare time (rather than making it your
full-time job), X is likely among your better choices.

Similarly, if you want to have a windowing system on your 486
(or comparable) system, X might end up being irreplaceable.
Anything with Libcairo inside will likely be both too slow
and too large to fit the filesystem space you'll have there.

For various reasons, not all of us always use hardware produced
in the last year or two.


X is network transparent.

It's still a thing we use, so in order to move on to some other
solution, that other solution needs to solve this for us.

Running a bunch of clients from different hosts on a single
shared desktop /is/ risky, in the sense that if /one/ client
is compromised, /all/ of them are.  Still, it's often an
acceptable risk if all the hosts involved are maintained by a
single person or team, such as in the case you operate a server
farm, or simply have several (essentially single-user) boxes
running at home.

When better isolation is desired, a separate X server can be
used, such as Xephyr.  Whether that is better or worse than
running (SSH- or TLS-tunelled) VNC or SPICE is debatable.


X maintains compatibility.

If you want or need to, you can still run X applications
from about four decades ago.  If anything, it's more likely
you'll run into issues with the C compiler or non-X libraries
compatibility rather than those with X's own.

While we won't expect a /new/ system to run applications from
before its own invention, it's imperative that an application
written for it /now/ will be compatible with the system's
version that will be in use four decades into future.

This is something that GUI environments out there seem to be
lacking in general.  You might say that GTK supports this, or Qt
supports that, but can you really take a GTK or Qt application
from 2004, build it on a contemporary system, and still have
all that advertised support?  The thing is: a modern toolkit's
lifetime is ten years or so.  Then it's discarded and replaced
with something with the same name, yet entirely new API.

Granted, I'm not much of a GUI person myself.  For one thing,
I prefer to keep most of my applications under GNU Screen,
and it's not something too compatible with GUIs in general.

Still, I've written my (tiny) share of GUI code, and I might
as well end up writing more.  If you think that I'll be happy
to port my code to yet another version of the GUI toolkit I
use on a thrice a decade basis, I'd rather you'll think again.

I rather like libXaw aesthetics, and I admire the stability
of its API, but I'm not too happy with its lack of support
for manipulating widgets with a keyboard.  There's libXm that
offers that, but it's not too popular, likely on account of
it having been proprietary through much of its existence.
Then there's Tk, which is neither part of X in any sense nor
even specific to X, but so far as I can tell, it's probably
the best toolkit an amateur can use these days, including for
API stability reasons.

It's yet another point that can be worked on, whether in X or
in some newer system, but so far as I know, largely isn't.

--
FSF associate member #7257  np. Who Disturbs my Slumber by EuchMad