Groups | Search | Server Info | Login | Register

Groups > comp.windows.x > #559

Re: why X

Show all headers | View raw

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

Back to comp.windows.x | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

why X Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2024-05-11 17:35 +0000
  Re: why X Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-05-11 20:07 +0200
    Re: why X Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2024-05-22 09:25 +0000
      Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-22 22:07 +0000
        Re: why X Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2024-05-23 13:57 +0000
          Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-23 22:00 +0000
            Re: why X Muttley@dastardlyhq.com - 2024-05-24 08:47 +0000
  Re: why X not@telling.you.invalid (Computer Nerd Kev) - 2024-05-15 09:37 +1000
    Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-15 00:48 +0000
      Re: why X not@telling.you.invalid (Computer Nerd Kev) - 2024-05-16 09:05 +1000
        Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-16 00:06 +0000
          Re: why X Computer Nerd Kev <not@telling.you.invalid> - 2024-05-16 17:18 +1000
    Re: why X Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2024-05-22 08:55 +0000
      Re: why X not@telling.you.invalid (Computer Nerd Kev) - 2024-05-24 09:41 +1000
        Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 00:29 +0000
      Re: why X Computer Nerd Kev <not@telling.you.invalid> - 2024-05-24 21:35 +1000
        Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-24 21:37 +0000
  Re: why X Bozo User <anthk@disroot.org> - 2024-05-20 06:43 +0000
    Re: why X Muttley@dastardlyhq.com - 2024-05-20 07:20 +0000
      Re: why X gazelle@shell.xmission.com (Kenny McCormack) - 2024-05-22 15:51 +0000
    Re: why X Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-20 22:29 +0000
      Re: why X Muttley@dastardlyhq.com - 2024-05-21 07:20 +0000

csiph-web