Re: why X

On 2024-05-14, Computer Nerd Kev wrote:
Ivan Shmakov <ivan@siamics.netremove.invalid> wrote:

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

 > XFree86 and later X.org used to include the TinyX servers that
 > stripped out all but the bare essentials for a small, relatively
 > self-contained, executable which worked (and still works) with
 > most X software.  The X.org developers lost interest in it many
 > years ago and removed it, though some forks exist.

Pointers?

It's not something I think I've ever used myself; and like
I've mentioned before, I'm not really interested in software
that is no longer maintained (unless I decide to maintain it
myself; but there's only so much productive time I can
dedicate to the effort, you see.)

That said, there's tinyx-wscons [1] in pkgsrc, which means
"maintained" in my book.  Somehow, the only binary listed is
for the previous NetBSD version (9.3), and only for x86-64 at
that, which may indicate it doesn't get as much maintenance
as it really needs.  Mayhaps someone here might look into
what's wrong with it?

[1] http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/x11/tinyx-wscons/

 > After fixing various compiler/architecture compatibility issues,
 > I've built the XFree86 Xfbdev TinyX server for the Raspberry Pi
 > and it runs fine on a RPi Zero.  Interestingly seemingly every one
 > of the X libraries built from the XFree86 sources was significantly
 > smaller than those built from recent X.org on the Pi as well.

Do you have these experiments recorded anywhere?  It might be
interesting to those dealing with minimalistic or retro systems.

My impression was that there was some work on improving i18n
support in X.org, and that's both a worthy effort IMO /and/
tends to lead to bigger binaries.  No idea if that's what's
happened here, though.

(As an aside, my hunch is that these size differences lead to
measurable differences in carbon footprint, too.)

 > The point is that efforts really haven't been directed at making X
 > smaller in the recent years up to when the paid developers switched
 > to Wayland, in fact the opposite has been happening.  It's therefore
 > unlikely that the same developers really care about improving that
 > with Wayland.

My point is that having, say, both Xrender and the "classic"
X drawing API is redundant.  But you cannot kill the former
because of performance (including network performance, as was
pointed out here in the news:E4loZOuxDjnPBjUj@violet.siamics.net
thread), and you cannot kill the latter because of compatibility.

I have to admit that modern X software has managed to maintain
a degree of compatibility the other way around, though.  For
instance, the X server I use for running such, Xtightvnc(1),
only lists 7 extensions implemented in xdpyinfo(1) output
(BIG-REQUESTS, MIT-SHM, MIT-SUNDRY-NONSTANDARD, SHAPE, SYNC,
XC-MISC, XTEST), and yet so far I've had no trouble running
Chromium, Darktable, Gerbv, Kicad, Lgogdownloader, LibreOffice,
Merkaartor, Openbox, Scribus, or Zathura, which is about
everything I'm interested in in modern X.  (And I'd venture
to guess that they only really require BIG-REQUESTS + MIT-SHM,
with XTEST as well for xdotool(1).)

I'd perhaps be interested in running Eureka and Hugin, but
those require GLX (the former as a compile-time option,
enabled in the Debian build), which tends to be too slow
to be usable when you stick to free software anyway.  (On
account of GPUs that do /not/ require proprietary software,
sometimes vaguely referred to as "microcode," or outright
misleadingly as "firmware," being so few and far apart as
to practically being non-existent.)

Those curious about why I use Xtightvnc(1), well, first, it
works about the way I expect it to work, and second:

    [17 May 2024] T  DSA-5694-1 chromium security update
    [17 May 2024] T  DSA-5693-1 thunderbird security update
    [15 May 2024] T  DSA-5692-1 ghostscript security update
    [15 May 2024] T  DSA-5691-1 firefox-esr security update
    [15 May 2024] T  DSA-5690-1 libreoffice security update
    [15 May 2024] T  DSA-5689-1 chromium security update
    [12 May 2024] T  DSA-5688-1 atril security update
    [10 May 2024] T  DSA-5687-1 chromium security update
    [09 May 2024] T  DSA-5686-1 dav1d security update
    [09 May 2024] T  DSA-5682-2 glib2.0 regression update
    [08 May 2024] T  DSA-5685-1 wordpress security update
    [09 May 2024] T  DSA-5684-1 webkit2gtk security update
    [08 May 2024] T  DSA-5683-1 chromium security update

    http://debian.org/security/

Sorry, but I'm not comfortable running the software like the
above on my "primary" box: it's either a separate machine, a
VM, or a container.  The last one is cheaper, so that's what
I use (even though it admittedly offers the least isolation
of the three); and VNC-over-SSH seems to work a bit better
than Xephyr + $ ssh -X for modern X software IME.

By the same virtue, I don't really need X proper for the
above, but I still need whatever is supposed to replace it
to work over SSH.  And I /do/ need X for Xterm and such.

(I do not use containers solely for modern X, mind you; the
same considerations apply to, say, BIND vs. Unbound and NSD.)

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

 > I sure wouldn't, various Qt programs that I've used got dropped
 > from the Debian package repo because they didn't support newer Qt
 > releases and the old ones reached EOL.  GTK is only better because
 > people seem to find it easier to build old versions on newer Linux.
 > I use various GTK1 and GTK2 applications, and the only newer one I
 > use regularly with the still-supported GTK3 is Firefox.

Which is to say, the claim that "GTK supports Wayland" is
misleading: "GTK" would include "GTK1," and that surely doesn't.

Curiously enough, GTK1 is still maintained in pkgsrc, as are
various GTK1 applications; see [2].

Also interesting is that even though "GTK" stands for "Gimp
toolkit," Gimp itself has apparently decided to stick to GTK2.

[2] http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/README-all.html

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

 > Indeed, and to little if any obvious benefit for the GUI software
 > I see.  When an old program just uses Xlib directly, it takes away
 > a lot of potential obstacles to making it work on a modern system.

I'd still prefer software that uses Xaw over that which uses
"bare" Xlib.  For all their flaws, .Xresources / Xrdb provide
a standardized and easy enough way to customize the look and
behavior of X applications.

FWIW, Tk has an implementation of a similar and compatible
facility independent of X proper, but there's still slight
advantage in libXt in that it also supports the Editres
protocol.  Sadly enough, about the only program to allow
one to use that, editres(1), seemingly stopped to work a
few Debian releases back now.

And it's something that always bothered me about GTK1 / GTK2
applications; and even though it's reportedly been rectified
for GTK3, by now I've largely lost interest, TBH.  I /do/ know
my way around classic X, and I use modern X applications
rarely enough that investing much time into learning how to
customize their look no longer seems sensible.

--
FSF associate member #7257  np. Early Frost by Shane Jackman