Re: why X

On 2024-05-11, Ivan Shmakov <ivan@siamics.netREMOVE.invalid> wrote:

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.
>

I have a broken key near the Return one. With
xmodmap I could rebind another one near left shift,
as it's duplicated.
Not an easy task with wayland.