The X-Windows Disaster (1994)

Re:The X-Windows Disaster (1994) by commandlinefan on Thursday March 05, 2020 @12:19PM (#22495649)

When I first saw X, I had already grown up with PCs, so the whole concept of running the “main program” on another computer just to display it on my computer seemed so illogical I thought I must just be misunderstanding it. I mean.. I have a computer right here, why not run the program on this computer…? However, if you think about it - the X philosophy was actually mostly correct (or at least more useful than it initially seemed), they just did it in a clunky way. We’ve been slowly migrating to web applications which are the same basic concept: the program runs on the web server and your browser displays the results. This actually is better from a security standpoint (the server can access data that isn’t distributed to the client) and a maintenance standpoint (I can deploy a new version to the server and it’s instantaneously available to all clients). Running a “program” remotely and displaying the results locally is so ubiquitous now that my teenage kids are confused by the entire concept of desktop applications. What I’d love to see, and wish I had the free time to implement, is a Linux UI based on something like SVGALib that doesn’t use X at all; just enough to run a terminal and a browser (and maybe an email client and a word processor if somebody wanted to write one).

[ Parent | on HN ]

Re:The X-Windows Disaster (1994) by trilinearnz on Thursday March 05, 2020 @07:44PM (#22500069)

I'd like to dig into this point for a moment. Why was it necessary to have a client/server architecture for a windowing system? Was it because X was developed before practical GUI alternatives were on the market? Did the computing power of institutional mainframes exceed that of the user-facing terminal systems (clients)? As time passed and "client-only" windowing systems came onto the scene, could the client/server design choice not have been revisited for greater efficiency?

[ Parent | on HN ]

Re:The X-Windows Disaster (1994) by brianpaul on Thursday March 05, 2020 @11:16PM (#22500950)

I think there's kind of two aspects to that (why client/server):

1. The X protocol was roughly like an evolution of the VT-like protocols which were used for text-based terminals back in the day. Those protocols supported cursor control, simple character-based graphics, and later, simple vector graphics. X was an evolution of that to deal with bitmapped displays, mice, etc.

2. Hardware was pretty expensive. Giving everyone in the office an X terminal was far cheaper than giving everyone a workstation. Again, that was an evolution of VT terminals vs. minicomputers.

Even X terminals weren't cheap. In the early 90's a monochrome 15" terminal could be a couple thousand dollars while the workstation was at least 10x more.

[ Parent | on HN ]

Re:The X-Windows Disaster (1994) by orbifold on Friday March 06, 2020 @12:49AM (#22501272)

The classical use case is EDA software, which still largely runs on Linux. I can run simvision (a cadence tool) on a large server with ~96 cores and ~1TB of ram and the spawned windows integrate (almost) seamlessly with my multi monitor MacBook Pro setup. That Software only supports Solaris (recent releases dropped that I believe), specific versions of Red Hat Linux and Windows. Large simulations easily consume all server resources and require a SSD raid to function effectively. This also isn’t software you want to have to install or maintain yourself, plus it need access to proprietary information protected by NDA, which is not allowed to be copied to private hardware.

[ Parent | on HN ]

Re:The X-Windows Disaster (1994) by pjmlp on Friday March 06, 2020 @03:23AM (#22501862)

Xerox graphical workstations, proprietary UNIX toolkits like NeWS....

[ Parent | on HN ]

Re:The X-Windows Disaster (1994) by s_gourichon on Thursday March 05, 2020 @12:34PM (#22495816)

The modern equivalent of SVGALib is Linux' Direct Rendering Infrastructure.

If you just want fullscreen app, you can run them on top of DRI.

For "a terminal and a browser" at the same time you have to create some sort of protocol for windowed display, and an implementation of one side of that protocol that provides window management, and apps would implement the other side.

People did that. They named the protocole "Wayland", the window management implementation "Weston", and a number of graphical toolkits can target Wayland (GTK, QT, SDL...). Ref: https://wayland.freedesktop.org/faq.html#heading_toc_j_2

As a sidenote, if you want to run such a program standalone, fullscreen, can you do that without running a "server" or a "window manager"? IIRC, programs intended for Wayland can run fullscreen on top of plain DRI (or perhaps only SDL provides this facility).

[ Parent | on HN ]

Re:The X-Windows Disaster (1994) by cycloptic on Thursday March 05, 2020 @12:51PM (#22496024)

The simplest thing I know of is the minimal Cage compositor for wayland, that only supports running a single fullscreen program: https://github.com/Hjdskes/cage

With some hackery, you could probably build this as a backend for GTK/Qt that would run the server in the same process. But I don't know how useful that would really be.

[ Parent | on HN ]