Groups | Search | Server Info | Login | Register

Groups > comp.windows.x > #513

why X

Show all headers | View raw

	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.

-- 
FSF associate member #7257  np. Who Disturbs my Slumber by EuchMad

Back to comp.windows.x | Previous | Next — 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