4 ms·
In practice this is a very niche use case, and the maintenance cost and architectural constraints it imposed are just not worth it. The Unix philosophy: do one
by azernik 7y ago
In practice this is a very niche use case, and the maintenance cost and architectural constraints it imposed are just not worth it.
The Unix philosophy: do one thing, and do it well. If you want a remote renderer, write a piece of software that does just that, specifically.
- dredmorbius 7y agoX11 did that. It has clients, doing their client thing, and a server, managing the display details. Yes, this means that unlike many C-S architectures, the server is the part nearest the user and the client (may be) further away. But each did its respective job and stuck to its knitting. Keep in mind that when X11 was first created, and for much of its early life, through the 1990s, it was used for remotely accessing another (or multiple other) systems. The networking capability was baked-in. Nevermind that security was bolted on later, here, have a MAGIC_COOKIE....
- TheDong 7y ago> The Unix philosophy: do one thing, and do it well You're trying to argue that there should be two distinct pieces of software, a local and a remote renderer, for simplicity. Rendering does not fit in that space well. The physical resource of a display and graphics card really only allows one renderer to run, so it's not really useful to say "just write two renderers, one local and one remote". The unix philosophy is not a good argument. It's a principal by which you can make decisions, but it doesn't always lead to good decisions and it's quite open to interpretation as well.