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.
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.
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.
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 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.
When an old program just uses Xlib directly ...
On 15 May 2024 09:37:51 +1000, Computer Nerd Kev wrote:
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.
So what's missing? Xrandr? XShm? XFixes? XComposite? XShape?
XTest? Xv?
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.
What sort of things have they been adding that could be removed?
When an old program just uses Xlib directly ...
You still want to use Xlib rather than XCB?
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
What sort of things have they been adding that could be removed?
No idea ...
On 16 May 2024 09:05:01 +1000, Computer Nerd Kev wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
What sort of things have they been adding that could be removed?
No idea ...
So this is really some kind of general hand-waving ?big picture? comment rather than an actual valid criticism?
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.
On 2024-05-11, Ivan Shmakov <ivan@siamics.netREMOVE.invalid> wrote:
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.
Not an easy task with wayland.
On Mon, 20 May 2024 06:43:26 -0000 (UTC), Bozo User wrote:
Not an easy task with wayland.
<https://wiki.archlinux.org/title/Input_remap_utilities>
(Just one of many I found with a simple web search.)
On 2024-05-11, Marco Moock wrote:
On 11.05.2024 um 17:35 Uhr Ivan Shmakov 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.
I think this will be "solved" by simply not shipping X11 anymore
in the future. There are already such ideas.
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.
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.
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.
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.
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.
It seems to me the main argument for Wayland is "Its not X". When you try and
find out what its actual advantages are you get vague nonsense about
security and lack of cruft and a faster graphic instruction -> hardware path >, which may be true but the difference will be minimal with modern X >extensions and all but invisible with 99.9% of graphical applications unless >you maybe care about 60fps vs 65fps in some game.
It's certainly possible for current X maintainers to step down
anytime they want to, but it's equally possible for someone to
volunteer for the task in their stead.
On 2024-05-22, Lawrence D'Oliveiro wrote:
On Wed, 22 May 2024 09:25:17 +0000, Ivan Shmakov wrote:
It's certainly possible for current X maintainers to step down
anytime they want to, but it's equally possible for someone to
volunteer for the task in their stead.
Of course, "volunteering" means "willing to do actual work", as
opposed to "carping from the sidelines".
There is no shortage of those willing to do the latter, but not so
keen on the former.
Care to remind the group what have been your (unpaid)
contributions to Wayland so far?
XFree86 and later X.org used to include the TinyX servers thatOn 2024-05-14, Computer Nerd Kev wrote:
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.
I don't think I've seen an emoji work there except in Firefox
(which I suspect renders such characters itself as graphics).
On Thu, 23 May 2024 13:57:22 +0000, Ivan Shmakov wrote:
Care to remind the group what have been your (unpaid)
contributions to Wayland so far?
If you want to know what I’ve done for Open Source, search for my name >online.
Also interesting is that even though "GTK" stands for "Gimp
toolkit," Gimp itself has apparently decided to stick to GTK2.
It looks like it's just taking them a long time to rewrite [GIMP] for
GTK3 ...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 325 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 84:30:03 |
| Calls: | 7,164 |
| Files: | 12,543 |
| Messages: | 5,534,333 |