Network transparency meant that when I was doing Finite Element Analysis on the beefiest Sun workstation they sold, running a proprietary application, I could log in from home, run the application on the Sun, and see the results of the prior run.
I could edit the model, regenerate the mesh if needed, and kick off another big batch run, and then drop the X11 frontend GUI.
Over dial-up, from a Windows box to a Sun workstation, in the mid 90s. And it was could be secure, tunneled through SSH.
I'm assuming that was sending OpenGL 1.0 commands over the network, or doing some kind of equivalent. Using X11 drawing commands for that would have resulted in miserable frame rates over dial-up if you ever tried to rotate or zoom the mesh. In any case that's not really network transparency nor is it really X11, the program likely had to be built in a very specific way using display lists.
CAD and Simulation Apps were written in those specific ways.
You are right.
Where that was done, performance was excellent.
It just seems wrong in that case to to say that X is network transparent. The real concern is that OpenGL 1.0 was capable of running over the network, and in order to use it effectively application developers had to take network operation into consideration, and the server had to support the non-standard extension required to use it correctly. In some circumstances using display lists locally could actually reduce performance, so the application may not have wanted to take that path in all cases: https://www.opengl.org/archives/resources/faq/technical/displaylist.htm https://www.opengl.org/archives/resources/faq/technical/disp...
Generally if your application has any code that does this:
if (client is remote)
...
else if (client is local)
...
Then I wouldn't say the protocol you're using is network transparent.
Open GL could run over the network because X could.
Sgi used X fully. They wrote the book on all that, including GLX, and it was flat out awesome.
The Apps I used all ran display and pick lists. They worked very well over the wire and that use case for used a lot.
The quibbles are really getting past the basic idea of running an app remotely on ones local display.
That happened and worked well and had some advantages. I personally built some pretty big systems for modeling and simulation that were cake to admin and very effective on many other fronts.
Notice I did not say network transparent in my comments above.
Multi-use graphical computing is much more accurate when it comes to how X worked and what it delivered people.
BTW, display performance on those was great local. A small hit locally is not that big of a deal. Never has been.
Users will employ detail limits, model scope limits, whatever to get the UX they need.
Developers can dual path it, or provide options. And they will provide options because not all users have latest and greatest. They never do.
In the end, it is mostly a wash for most things.
The big gains were had in other areas.
In the CAD space, sequential CPU is far more of a bottleneck. Mid to lower grade GFX subsystems perform more than good enough for a ton of cases today. Can't get a fast enough sequential compute CPU. And while there is serious work to improve multi threaded geometry, fact is most important data is running on crazy complex software that needs the highest sequential compute it can get.
Big data actually sees a gain with the X way of doing things.
Huge model data running over shared resources is a hard problem. And it continues to be one. Mix in multi user and it takes serious tools to manage it all and perform.
In the 90's, many of us were doing those things, multi user, revision control, concurrent access, you name it on big models and fast, local file systems. There was software with all that well integrated. We did not have cloud yet. Not really.
The app server model rocked!
X made all that pretty easy. One setup, and just connect users running whatever they want to, so long as a respectable X server is available, they are good to go.
One OS, the whole box dedicated to one app, fast storage, big caches, multiple CPUS all tuned to get that job done well and perform.
Once that work is done, doing things the X way means it stays done, and users just run the app on the server. Bonus is they can't get at that data directly. Lots of silly problems just go away.
And, should that system need to be preserved over a long period of time? Just do that, or package it all up and emulate it.
In all cases, a user just connects to run on whatever they feel like running on.
Those of us still talking about how X does things see many advantages. Like anything, it is not the be all end all. It is a very nice capability and a "unixey" way of doing things being lost.
It is quite possible it just sent draw line requests as a list of vertexes after doing all the math on the client, which core x supports just fine.
It means that _today_, I can run an IDE on my 32-core home desktop and interact with it seamlessly on my 13-inch laptop at the office. I'm not sure whether this is possible with Wayland.
https://wayland.freedesktop.org/faq.html#heading_toc_j_8 https://wayland.freedesktop.org/faq.html#heading_toc_j_8:
Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier.
It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share a window on the fly with a remote wayland compositor, for example, a friend's desktop.
NX partially solves the problem that applications don't use the X primitives anymore and are way to chatty with the X server (which leads to many unnecessary roundtrips which is the real killer for remote X11). Old applications work great even without NX or any hacks.. just anything modern is quite sluggish.
And it's less about the actual protocol, but the desired behavior.
I want to launch applications on a remote machine and have the windows appear on my local machine as if I was running them locally. And so far there is nothing except X11 that can really do that..
>And so far there is nothing except X11 that can really do that.
In terms of Wayland there is Waypipe. And I believe Citrix has been doing this forever on Windows, although I've never used their products.
In my opinion Xorg by itself can't really do it correctly, I find running remote clients to be basically unusable without Xpra. And in order to really use that effectively, you have to be running all your clients within Xpra from the start.
All of that said, "ssh -Y" works pretty well for me. It's pretty usable.
And from a user perspective I personally like the "application connects to render" model much better than VNC or RDP style entire-desktop streaming.
IIRC it used to work a lot better (like, a whole lot better) but modern X apps mostly end up sending bitmaps over the wire, rather than native X rendering instructions.
Agree that it works better than other remote desktop options on Linux. Overall though I get better performance with RDP to Win10 running Linux in Virtualbox (!) than any other option I've tried though, including Linux on bare metal with a variety of remote desktop options, and Virtualbox's remote desktop server.
I'm not clear on what you're missing. What meme? The protocol is well documented. The basic abstraction is that there is a separation between the 'processing' part of an application and the 'display' part of the application and those two parts communicate using the X11 protocol. That conversation can happen over a local or a remote socket, or shared memory. The practical use cases are that I can have an application running on my local machine, or one on the other side of the world, and the 'display' portion is consistent. Not much different than, say how Citrix uses it's own protocol to draw remote displays.
It allowed a 'mainframe' model where you could have a very fast, expensive application servers that could display to less expensive local resources, and mix the display with local applications. So my heavyweight applications could run on the monster Sun or Cray in the datacenter, but my clock, calc and notepad app ran locally, but all in the same display.
Yes, over the years things like MIT-SHM and NX came along to paper over problematic issues in X11. And yes, there are other, possibly better ways so solve it now. But in the late 80s and through the 90s, it was pretty cool stuff.
It's possible I'm a bit jaded because I spent a long time working on things like Wayland and next-generation graphics technology, where people would suddenly show up and name-drop the terminology "network transparency" as if it meant something, or solved useful problems.
I just find it funny that CORBA-style RPC is now considered a dated, bad approach in the world of distributed systems, but the same thing in the X11 world is considered way ahead of its time and a design ideal.
https://www.omg.org/gettingstarted/history_of_corba.htm https://www.omg.org/gettingstarted/history_of_corba.htm
CORBA 1.1 (February 1992)
This was the first widely published version of the CORBA specification. It closed many ambiguities in the original specification; added interfaces for the Basic Object Adapter and memory management; clarified the Interface Repository, and clarified ambiguities in the object model.
https://en.m.wikipedia.org/wiki/X_Window_System https://en.m.wikipedia.org/wiki/X_Window_System
X originated at the Project Athena at Massachusetts Institute of Technology (MIT) in 1984.[1] The X protocol has been at version 11 (hence "X11") since September 1987.
Not that anyone feels it is important today, but X11 is multi user graphical computing.
A display server can display anything any user connected to it wants to display.
Actual 90's era use cases:
Application server. One copy of 3D CAD, one database, 30 users all running on a beefy machine well up to the task.
Each ran via X talking to the app server. Admin was cake, data big model access was fast, no user could actually touch the data except through use of the program.
User having trouble, push a window onto my display. I fix it, close window.
Display wall, conferencing. Big wall display, multiple users display data on it, one management user handling windows, etc...
Display wall, many small displays, each running via workstation. App sends display data to all of them.
Distributed computing resources:
Once, just for fun, I had an application data shared via a machine running nfs, fonts served by another machine, yet another machine running the application, yet another handling window management, all displayed on yet another machine serving the display and taking input.
(BTW, it was possible to literally kill the window manager and launch a different one and the display would shift a bit and the user continued along still running their app, but now using a different window manager!)
User could click on an icon, all those machines contributed to the app experience. Was hard to tell the difference between that and it running all locally.
Why?
Linux user wanted to run CAD unavailable on Linux, was developer who wanted a Linux box. So I used X to push the whole experience to their machine and distributed it for fun once it was working well just to learn and really push things, frankly.
While running, it was hard to tell the Linux machine was not an expensive commercial Unix machine.
All that was over 10-T and 100-T ethernet BTW.
Well designed X applications, particularly those using the SGI GLX extensions ran very well on local LANs. Poorly designed ones were nowhere near the quality of experience.
That skill was expensive. I think this is a big part of why so many struggled with X. A browser, for example, would not be comparable, pretty terrible.
Displaying web pages sucked, yet modeling a freaking car was amazing!
At the time, the X implementation of multi user graphical computing allowed for these and other combinations of users, machines, displays and applications.
It was well thought out multi user graphical computing!
The users could be local, as in a multi head machine offering two sets of keyboard, mouse, display, or they could arrive over the network.
Same as the Unix it was built on top of.
I think that is what people really are trying to get at when they say "network transparency"
Not all these use, or the set of possible use cases X made possible, make sense today.
But, when it was done?
Nobody knew, so they made a system as capable and that employed the best ideas in multi user computing, so that it was all possible.
That's why people who got to understand and really use X appreciate it as we see them do today.
> Nobody has ever explained to me what it means, what its goals are, what constraints it has on the system or the protocol.
In today's world, what I think people want to do (and certainly what I want to do) is ssh to a machine, run a graphical program on that machine and see and interact with it in my graphical environment. X11 with ssh tunneling lets me do that. It's not a great experience, for all sorts of reasons, but it's an experience, and people who have been around for a while remember that it used to work better. It's usable enough on many applications to work in a pinch, or for ocassional work (I always run mythtv-setup via remote X, because it's inconvenient otherwise; sometimes I run a graphical browser over remote X to access localnetwork only servers from outside my home, but only if I can't get proxying to work, because browsers on remote X are awful in 2020 in ways they weren't in 2005)
I haven't looked in a while, and maybe waypipe fills this gap now, but I think at least some people are frustrated because Wayland is supposed to replace X11, but it doesn't hit all their use cases, and they may not care that much about the things it does better because they were used to the old ways. (Of course, if those things include hardware support, that will be a forcing function).
I certainly understand your frustration though. You built something new and better, and people won't use it because they're stuck on something that barely works.
It's not a great experience, and it doesn't work at all with everything that uses video acceleration (like a modern browser, and as a corollary all Electron applications).
In contrast Windows RDP protocol works much better, even if it's sending the whole desktop as a video stream, and works even on modest connections (like a 20mbit/s ADSL).
In fact nowadays I would argue that the method used by Xorg is no longer ideal: the commands that needs to be sent between the application and the GPU are too big to be sent on a network connection. Instead we got much better video compression algorithms, so it's better instead of sending on the network the commands to draw the application to just have the server GPU render the application and then send a compressed video stream to the client.
> It's not a great experience, and it doesn't work at all with everything that uses video acceleration (like a modern browser, and as a corollary all Electron applications).
I'm posting this with Firefox 79 running on FreeBSD, displayed on Windows (VcXsrv) via remote X over ssh (gigE lan because I'm at home). Not sure how much modern I need to get. chromium-84 also installed and worked enough. Scrolling is glitchy, and I don't dare watch a video[1], but either would work enough if I need to use a graphical browser to administer some network device remotely (I used to be able to use w3m for a lot of those)
I'm sure RDP would be better, but it doesn't fit my use case. I don't want a whole desktop, just one window, and I do need it to tunnel through ssh, and it's nice when it's a simple setting, so I can just run a program and it shows up. If there's an easy way to tunnel RDP that I'm not aware of, I'm happy to learn, especially if the experience is better, but if it's super fiddly, I'd rather use what I know and what works, even if it's laggy and awful.
If RDP worked like X, I'd love to setup a beefy windows server in my basement and play games on it via RDP from my PCs around the house. If anyone has tips on that, would love to read them. (Requirements: single server, three simultaneous users, single GPU ideal, but flexible; want to play Civ V etc with the family. Cost (including licensing) needs to be comparable with three low tier desktops (i3-8300 ))
> In fact nowadays I would argue that the method used by Xorg is no longer ideal
Again --- I know it's not ideal, it's just less fiddly and I already know how to use it, and it how to make it work hasn't changed significantly in the last 15 years (mostly the windows X servers are better and crash less), and desktop applications tend to be more synchronous and harder to use over high latency connections. I'm not looking to run all my applications from the other side of the country, I just want to occasionally run a couple things from home when I'm not there, or to setup my HTPC with a mouse and keyboard instead of a remote control.
I think everyone will hate me for suggesting it, but I could imagine an X11 extension where if the client is not local to the server, it would switch to rendering everything locally and sending compressed video; I don't expect anybody to build that, but there's no reason you couldn't do it. It wouldn't solve important issues like head of line blocking, of course.
[1] Ok, for giggles, I tried to watch something on youtube. It was surprisingly decent. Lots of tearing, and I don't know where the audio went (clearly, not over X which doesn't do that, not sure if it was playing on the X client host), and it took a long time to stop the video because I'm guessing a whole ton of frames were buffered. But, I got the idea of the video, and it didn't kill the session. If I were doing this over my WAN, it would be a lot worse, clearly.
> Nobody has ever explained to me what it means, what its goals are, what constraints it has on the system or the protocol
You answer it later on. They want something like NX. We can fill in the details as one pleases.
> We know how to design much more resilient systems than that.
I think you are overstimating the progress of computer/network engineering. Anyway, CORBA's "transparency" might be a thing of the past, but what's the point here? Unless you plan to make a graphics API explicitly asynchronous, what alternatives you have? Sending PostScript over the wire? :/
The users want graphic primitives sent through the wire.
There is not much alternative other than CORBA style RPC.
> Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years
That is not true. See how many commercial Qt engagements were stuck with Qt 4 because Qt 5 initially forced to use Qt's local rendering and only pushing the final pixmap to the server. Multi-million CAD machines slowing down to a halt because the clients were suddenly sending megabits through the pipes * . Eventually they had to backpedal and Qt5 now offers coreX/Xrender rendering too. _Most_ toolkits _to this day_ still render with X by default, and people do notice when this changes (see Mate). Sure there are exceptions and likely amongside the most used software (e.g. browsers), but I'd hardly claim "anything but MIT-SHM is all that matters for the past 20 years".
> is a network-designed fork of the protocol,
Yet compatible (to a high degree, at least). Up to the point the "transparency" illusion is maintained.
> Problems like remote desktop and streaming can be solved by other solutions
The biggest problem is that once you drop the codeflow on most opensource programs that renders using X, it's code that's rotten forever, and this entire method of "network transparency" will never be workable again in the free desktop world. Everyone and their mother will draw in a different way.
We'll have to resort to full video streaming or the like that have their own share of disadvatanges. There is absolutely no technical reason behind this, it's just a "code is done by volunteers" problem.
* And please don't say VNC/video here, since this is CAD. It's mostly a several megapixel black bitmap with a couple million white lines rendered on it. Relatively easy for a "drawing primitives over the wire" solution, insane for anything that tries to encode it as realtime video.
>See how many commercial Qt engagements were stuck with Qt 4 because Qt 5 initially forced to use Qt's local rendering and only pushing the final pixmap to the server. Multi-million CAD machines slowing down to a halt because the clients were suddenly sending megabits through the pipes
Is there a bug report for this in the Qt bug tracker that you can share?
>It's mostly a several megapixel black bitmap with a couple million white lines rendered on it. Relatively easy for a "drawing primitives over the wire" solution, insane for anything that tries to encode it as realtime video.
I think your math is off. In the X11 protocol, each line segment is transmitted as 8 bytes. Transmitting two million white lines uncompressed is going to take up 16 megabytes. Do that 60 times a second and now you have a bitrate of 960MB/s. Compare this to youtube's recommendations which suggest a maximum bitrate of around 10MB/s for 4K HDR 60FPS video: https://support.google.com/youtube/answer/1722171 https://support.google.com/youtube/answer/1722171
To me, the compressed video solution is the clear winner.
I'm afraid I'm dreadfully confused by your comment.
"The typical answer I see is "you can send the same bits locally that you do over the wire", but nobody ever explains why that's even desirable for a network protocol."
Yes, you can use a network protocol to chat between local processes as well as between remote processes. Desirable? It's impossible to avoid...
"Transparent, distributed RPC was tried in the 90s and largely judged a failure."
True (ahem[1]), but irrelevant. X isn't a remote procedure call system.
"Not to mention that ever since the introduction of the MIT-SHM protocol, which is used by most everything to transfer image data, it hasn't even been true in practice for the last 20 years. Most modern enhancements to X11 have been about taking the X server out of the loop for as much as possible."
This is true; network speed hasn't kept up with graphics power and requirements for the most part, so processing has been pushed to the client. On the other hand, HTTP/HTML/JS/CSS can be seen as a poor-man's reimplementation of X (or more closely, of Plan 9 client-ui/server-processor protocols). And for the 20 years previous, clients were underpowered in comparison with a big honking machine you could log into remotely (or at least a dedicated machine that didn't have to bear the weight of a graphical interface).
"To make X11 usable over the network..."
X11 has been usable over the network since 1987 (and X < 11 before that) (https://en.wikipedia.org/wiki/X_Window_System#Origin_and_early_development https://en.wikipedia.org/wiki/X_Window_System#Origin_and_ear...).
"...even advocates of the principle usually use something like NX which is a network-designed fork of the protocol..."
I'm not sure what you mean be NX. The...
"NX technology, commonly known as NX, is a proprietary software application for remote access, desktop sharing, virtual desktop on Linux and file transfer between computers. It is developed by the Luxembourg-based company NoMachine which also lends its name to the software." (wikipedia)
which has nothing to do with X other than being descended from one of the low-bandwidth X extensions. (Not the low-bandwith X, and low-bandwith means dial-up. Plain ol' X was pretty chirpy on a SPARCstation with 10MB ethernet.)
"...multiple independent streams so we don't have reach head-of-line blocking with roundtrips..."
Welcome to the wonderful world of TCP.
"...and client-side rendering."
Once upon a time, there was a thing called a Sun Ray (https://en.wikipedia.org/wiki/Sun_Ray https://en.wikipedia.org/wiki/Sun_Ray), basically a (non-3d) graphics card glued to an ethernet card, that was used as a thin client for a Sun server. I didn't see one until after I'd used an IBM X-terminal (a smallish pizzabox that ran the X server and pointed everything else at a bigger IBM box) for several years and the latter was much better than the former.
[1] Protobuffs, et al., notwithstanding.
Back in the 90s, I had a serial cable under the carpet from my computer to my couch. My computer would access the internet over PPP and my laptop would PPP over to my computer. Then I would launch netscape and browse the web from the comfort of my couch.
I have had a couple other use cases over the years like virt-manager at work, and a graphical management tool that I made for my son's minecraft server.
Sure there were other solutions but X11 over the wire worked well.