3 ms·

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 b

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?

brianpaul 7y ago
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.
orbifold 7y ago
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.
pjmlp 7y ago
Xerox graphical workstations, proprietary UNIX toolkits like NeWS....

brianpaul 7y ago

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.

orbifold 7y ago

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.

pjmlp 7y ago

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