Re: why X

From	Bozo User <anthk@disroot.org>
Newsgroups	comp.windows.x
Subject	Re: why X
Date	2024-05-20 06:43 +0000
Organization	A noiseless patient Spider
Message-ID	<slrnv4ktqj.pi7.anthk@localhost.localdomain> (permalink)
References	<E9TTqC5XlaglCPCF@violet.siamics.net>

Show all headers | View raw

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.

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