I agree. Such bullying is uncalled for in this forum.

I just wrote a very long post with a lot of detail, and then lost it all when I accidentally closed the window. This forum does not save drafts, apparently. It is discouraging to say the least. I will try to summarize my points:

Terminology: "remote desktop" is an overloaded term. It could be a "generic" usage or it could refer to Microsoft's proprietary Remote Desktop (RDP) protocol. I use "remote control" for the generic term and "RDP" or "Remote Desktop Protocol" for the Microsoft products.

X11 has been around for a very long time. I remember using it in the late 1980s or early 1990s. It is the foundation for windows management on Linux. (There is also Wayland as a potential future replacement for X11, mentioned for completeness.) I am not sure how X11 would work with a full desktop and no overarching protocol like VNC or RDP. If it were as simple as creating an SSH tunnel and running a full Linux desktop through Xwindows (X11) alone, it would have been done and easy. Sure, you can bring back an Xclock or Xterm or Xeyes, but the full desktop eludes me, and does not explain the many other solutions that seem to require more.

VNC: This is the "default" solution for Linux. It has been around for a while and forms the basis of many solutions (see below). VNC is not secure, and must be tunneled through SSH or TLS (SSL).

Remote Desktop Protocol (RDP): Microsoft's proprietary solution for remote control of Windows systems. Apple has Apple Remote Desktop for macOS. It is similar. RDP is not native to Linux, although RDP servers for Linux have been developed. This is the protocol behind Linux solutions with "rdp" in their names.

Both Microsoft and Apple proprietary protocols are elegant solutions that are comparable to being on the remote system itself. It is not so for Linux solutions. I tried several different solutions myself. Among other issues I encountered is that some require the remote session to be active to connect to it. It is not as simple as a login screen and logout when you're done. User switching may not work as expected either. Everything about remote control of Linux seems "kludged".

There are also third-party products that you can use. TeamViewer and NoMachine are examples and I have seen discussions about RustDesk. I choose to avoid them. I would like a self-contained, self-hosted solution and would prefer to avoid third-parties who provide the management, control, and proprietary closed source software. ... but people report that they work the best. Some are available free for personal use.

Network / internet latency and throughput ("bandwidth") can affect performance.

Every solution I have seen requires the window manager and desktop environment to run on the server itself. I have not found or seen anything where those functions are performed on the client. It sounds more like a proof-of-concept exercise for a grad student and is probably way above @SamHobbs and my pay grades. I recommend that Sam try a few of the existing solutions by setting up two virtual machines on a virtual network. That is what I did. Keep in mind that virtual machines eat RAM and disk space.

Here are some of the solutions I tried. I got a few working and few need more work. I put that project on hold months ago. I will pick up later when I can free more time. Here are solutions I tried, but all of them require the desktop on the server side, and they all had "session" issues where you couldn't log out (or it reactivated the desktop anyway), stuff like that:
VNC - Digital Ocean has a good tutorial for VNC over SSH running on Debian, to give you one example. There may be pre-canned solutions that I did not try. I did not look at TigerVNC or noVNC or KasmVNC.
xRDP
XtoGo
Xpra - recommended by one of my children who prefers Arch Linux.
Guacamole - A server that displays the remote control in a client's browser window.

PM sent to Sam with additional non-public information that may help. (No, I will not send it to others. Edit: NOT! Sam does not allow PMs. Too bad, I had good stuff to share and was going to break one of my own security rules to do it. Their loss.)

... and dang! the previous post that was lost was much better. Oh well.

1 members found this post helpful.

Your "summary" is four times longer than any other post in this thread. :/


Re-read post #1, then re-read post #12 and #15. X11 forwarding is precisely what has been asked for, (and this was already realized/acknowledged by Sam in post #9).

Also, X11 forwarding aside, consider that far from being a rare "grad student proof-of-concept exercise", you're also interacting with a non-graphical server which sends instructions to a client-side GUI right now.

1 members found this post helpful.

Seems more unusual for someone to get an answer/information and do nothing with it. You were told specifically look at SSH X forwarding, and just type in the name of the GUI program. Seemed to be 100% what you wanted. Did you do any research about X forwarding? Read the SSH man page??

And when X windows was mentioned, you seemed like that was new knowledge...despite it being the reason you have a GUI in the first place, and that every distro of Linux uses it.

I sent a message to moderators about a year ago and months later they replied by saying I should report problems. I reported a previous message in this discussion but the moderators seem unwilling to take action. My only other option is to find a different forum in the future. Probably that is what many others have done.

That type of thing has happened to me. It is frustrating. Sometimes I compose my reply in a separate editor that does have a backup.

The Remote Desktop Protocol was introduced by Microsoft with "Terminal Services" that relied on Citrix technology. Citrix used DLL injection and I think I read that they used Microsoft Detours to do the DLL injection. Therefore I am nearly certain that the way that RDP works is that the calls from a GUI application to the desktop environment (that could be Windows) are intercepted and sent to some other system. The application is written as if the GUI is in the same system and does not support a GUI anywhere else.

The terms server and client need definition in this context. As has been said, the way X Windows works, for it the terms are the reverse of what many expect. With X Windows, the server is the system with a GUI (such as Windows) and the client is the system where everything else is done (such as a headless VM). I have confirmed that the client system does not need a desktop environment to support use of the server for a GUI.

I am retired. I do not have a pay grade. Development of a system such as this requires basically two things. The first would be a mechanismn for communicating; for proof-of-concept it does not even need to be secure. The other is the graphics to draw the GUI. Perhaps the third is the design of a GUI. There are many existing GUIs with source code that would provide graphics source code and at least a start on a design.

Look at a previous reply. I already did, except I used a DigitalOcean Droplet VM and my local Windows.

I doubt that I turned them off intentionally. And when I look at my profile Receive Email from Other Members is enabled. I added a website to my profile. You can send email to Sam@ that domain.

TB0ne, you're coming across as cranky and petulant.

After you mentioned X forwarding in post #3, Sam clearly started looking into it.

They specifically stated it might be what they want, but expressed concern at the comparison with RDP (which they know is not what they want), yet clearly continued to experiment and posted in #9 that they had a working test.

Just because Linux distros use X11 doesn't mean that the millions of people using those distros automatically know what it is or that it can be forwarded over SSH.


One must have at least 150 posts before being able to use the PM system. (In addition, there's also a specific toggle; I don't recall if it defaults to on or off.)

1 members found this post helpful.

Yep, especially after having dealt with the OP several times in the past:
https://www.linuxquestions.org/quest...on-4175707052/
https://www.linuxquestions.org/quest...et-4175704165/
https://www.linuxquestions.org/quest...ww-4175704502/
https://www.linuxquestions.org/quest...ws-4175704237/

OP seems to have a problem doing basic research, or paying attention to what's said. The thread about Windows hibernation is a good example. And for someone old enough to be retired, it's odd that their feelings get hurt by asking them to do so.
They may have, but we only know what is posted, not what someone means. Post #4 doesn't indicate anything was done to look at SSH X forwarding, only that X windows 'might' be what they're looking for. And any bit of basic research on the topic would lead someone with at least two years of Linux experience to know what X windows is, and how it's used, but the OP didn't do that.

The OP was also told to just type in the name of the GUI program, and post #7 even had a direct example, which was used in post #9.
There is, and you can allow/disallow them as you'd like through your control panel.

You are right, and thank you for pointing it out. It has been a long time since I have used Xwindows and X11 in that way. Yes, the web browser does a similar function.

Right now, I am trying out ordinary X11 over SSH to see how applications can be displayed through it. It has been a long long time.

It begs the question: If X11 is a real solution, what do VNC and RDP have to offer? Why so many alternate solutions?

Acknowledged. This thread is about remote control / remote display, so I have nothing further to say.

"Gentlebeings," please try to remain focused on the topic that you started, and strive to keep "personalities" where they frankly don't belong.

When you do "anything GUI" with a Linux/Unix system, you are in fact using either "XWindows" or "XOrg." (The former of which, despite the name, has zero to do with Microsoft.)

As I've said, this is a client/server architecture which was originally built for "vastly-underpowered" networks. (Yes: think "telephone modems.") In this design, the "server" sends drawing commands for the "client" (your machine ...) to carry out. This allows you to have a decent or even very-good user experience while minimizing the demand on the communication line. (It wasn't quite "Morse Code," but it was damned close ... Ahem.)

And so, even to this day, your Linux/Unix computer is actually doing the same thing. But the "client" and the "server" components are usually running on the same box.

But to clarify ... The remote ("server") system does(!) need to be running the "graphical environment" that you are connecting to, even though it perhaps has no (and does not need ...) any "inherent graphic capabilities" of its own.

Remember that, this scenario, your ("client") computer, in its role as a "client," is passive. It is acting as a "definitely not 'dumb' ..." terminal! The "host" computer to which it is connecting must therefore be "running the show entirely," although it is efficiently doing so by means of "drawing commands" and "mouse-click messages."

With an obligatory nod to Microsoft's engineers – "they did what they had to do, and did it well" – the "Linux/Unix 'remote experience'" is actually quite clean and impressive by comparison. (P.S.: Of course both they and Apple provide very good "clients" for "our" use.)

https://www.tecmint.com/best-remote-...ring-software/

Most of the common client server ways. I used NoMachine way back and was impressed that it loaded it's own (gui) on the target remote if none existed.

All these solutions address controlling a remote host from a local host.
For a command line shell to command line shell, then SSH is the tried and proven technique.

If a single GUI program is to be run on the remote host with display on the local host, then SSH with X11 forwarding will usually work, but there can be slow performance with some applications. (The local host needs to have an X session running).

If you want a full GUI desktop running on the remote host to appear on the local host, then you need a server daemon running on the remote host to accept the incoming connection and transfer the display to the local host. VNC and XRDP can do this by starting a new X session on the remote host. The protocols are optimised for transferring GUI updates.

This gets more complicated when you think about how to make connections and securing those connections.
Unless in a trusted local LAN, VNC and RDP need to be tunneled through encrypted connections.

The remote host may be behind a firewall that does not allow incoming connections. Solutions like TeamViewer and AnyDesk operate servers that can accept a connection from the remote host and make that available to the local host on demand over encrypted connections. This is all seamlessly provided to ease the user experience.

Solutions can also vary by the experience that is offered. The NX technology of NoMachine is highly optimised for display transfer. The ability to use (and control access to) resources on the remote host (e.g. audio, networked drives and connected devices) may also be important.

Needs vary widely so there is no one size fits all.

1 members found this post helpful.

I am not familiar with VNC but RDP is not an alternate. I am asking about solutions for requirements that RDP does not solve.

I tried to make it clear that I do not and that that is off-topic.

And since you don't say what RDP doesn't solve, and have been given a term (VNC) to research, what do you think we can glean from this?? You don't tell us what 'requirement' that RDP doesn't solve, nor does it appear that you've researched what VNC is. Putting "what is linux vnc" into a search engine (Google has over 30 million results) will give you ample reading material so you can research it on your own.
And we have ALL tried to make it clear that you use X forwarding over SSH to do EXACTLY what you want. You were given the terms, examples, and even said that you tried it and it worked.

1. Type in "man ssh" at a terminal; read the SSH options.
2. Type in "how to run gui linux application over ssh" into any search-engine and press ENTER. Read some of the results; since Google has 28.8 MILLION results for that, is that ample enough documentation to look at (since you claim to read such documentation?)

Is there anything else you need to be able to move forward???

ssh and X forwarding is slow if you intend to do things such as using a web browser. vnc is considerably faster, especially if you use something like tigervnc for both the server and client.

I'd suggest reading up about setting up a kvm/qemu virtual disk/machine, installing a CD/DVD (operating system) into that, and then booting it with the -vnc :1 (or whatever DISPLAY number) option as part of the qemu boot command, i.e. vnc outputs to port 5000 + the display number. Any device that can run a vnc client/viewer can then access/control that system (graphically). And the server on which the vm is installed/running doesn't need any graphics - as its all being run in a virtual machine.

Another qemu switch enables you to forward ports from the virtual machine to the host system, for instance ...

has the virtual machines port 22 (ssh) appear as the hosts port 2222 and the virtual machines port 5901 appear as the hosts systems port 55901, so that way you could run vncserver inside the virtual machine, where its port 5901 to access that, appears on the host systems port 55901, so if that host systems IP was 192.168.1.10 then another box that ran vncviewer 192.168.1.10:5901 ... would connect to the virtual machines vnc.

So fundamentally the benefits of vnc over X is that its faster, and more universal, the client doesn't have to be running a X based system, vnc clients are available widely from phone to ... well pretty much most things.

I do all my qemu setup from the (nix) command line, many prefer to use gui's to do all of that and its relatively easy, you'll likely find many youtubes to help if you struggle. Once you have that vm set up and running then its a relatively trivial step to transition that to outputting to vnc and using a vnc client to connect/control that from another box. The main stumbling blocks there is the tendency for the flow to be blocked by a firewall. Which can be fixed by using the likes of ssh tunnels or vpn (or if you have the authority, opening up the relevant port(s).

For me, setting up a qemu virtual disk of 20GB size ...
qemu-img create -f qcow2 default.qcow2 20G

If I have a OS install iso image, with a filename of cd.iso, then to boot that and install it into that virtual disk ...

qemu-system-x86_64 -m 2048 \
-cpu qemu64 \
-vga std \
-cdrom cd.iso \
-drive if=virtio,file=default.qcow2,format=qcow2 \
-netdev user,id=mynet0,hostfwd=tcp:127.0.0.1:2222-:22 \
-device virtio-net,netdev=mynet0

\ means = single line continued, otherwise the above would extend out too long as a single line. The -m 2048 means allocate 2GB of ram to that machine, the rest are pretty generic. On a gui desktop system you should see that boot and can enter the install to hard disk actions required, and then shut that machine down. Thereafter you can boot using the same command, but just leave out the -cdrom cd.iso part, as that installation cd is no longer required and it should boot from the virtual HDD that you installed into.

Any other machine that can run that qemu, even though it may not have a gui can use that file (machine). If you add -vnc 10 ... to that set of switches, then when it boots it can be accessed using vnc to the host systems IP port 5910 (assuming that isn't already being used). And provide what was installed was a gui desktop/system then that vnc client system will see/control its gui desktop.

You can use other choices of format to qcow2, however that is the more flexible choice as it permits actions such as being able to take snapshots of the filesystem at a point in time, and roll back to that state. It also wont use up 20GB (whatever) file space, instead it will start of smaller and grow itself as required.