Is this just not an itch anyone has wanted to scratch in the last 25 years? On Linux you can maybe XWindows your way to a faster connection by what about Mac? Also, RDP seems to let me run GPU based stuff where as XWindows you're actually not seeing the computer's display.
Kinda yes kinda no? Mostly from X drawing commands being a shit way to represent modern UI's and toolkits. So everyone draws stuff on their own, since it's far more flexible and faster.
Same is true on windows. RDP is streaming video far more often than it steams drawing commands.
You could maybe build something that streams GPU commands, though. Use something like VirtIO-GPU + GFXSTREAM ( https://www.phoronix.com/news/VirtIO-Context-Type ) to stream to an entirely different computer instead of just to the VM host?
This is really fundamentally wrong. X drawing commands are still just fine for representing modern within-app UIs and toolkits.
The two things that have changed are the underlying GPU technology, which has shifted towards abstractions and APIs mostly targetting gaming and video, and desktop level UI stuff, which is expected to include compositing these days.
However, it's not as if the other remote desktop systems have really changed much to reflect these developments either.
Faster for which usage? Locally yes, but not remotely where it's worse..
In the beginning Unix desktops were optimised for LAN, and in the process of being optimised for standalone PCs to the dismay off those who access their Linux desktop remotely..
X11 is at its heart an asyncrhonous distributed systems protocol (quite similar to Erlang Dist) that happens to output to the screen as a side effect, but a lot of libraries and toolkits (including xlib) provide synchronous abstractions on top. When applications use synchronous abstractions frequently, you end up waiting for many roundtrips and the UI gets painfully slow. Some app developers regularly test with remote X over high latency and/or low bandwidth links, and some don't, and it's pretty easy to tell which is which. Some apps are painful even on a LAN, lots of roundtrips add up.
If there was appetite to do the work, one could imagine an extension to push client-side rendered window images across in a compressed format, but xorg developers have mostly moved on. There's nx and other external compressors, but there's a missed opportunity, IMHO. Maybe waypipe will fill this void eventually?
Take Xterm, for example. I did benchmarks over remote systems long ago. When it came to performance over the network it was absolutely trounced by Gnome-Terminal. And Gnome-terminal was a lot slower then then it is now. The reason was because Gnome optimized text output on scrolling text that minimized the latency impact. And it still sucked.
There was a reason that it never saw widespread use in the enterprise outside of very nitch sysadmin users on pretty much local area networks.
Were as Windows has been used to support thousands of users in a single environment with almost entirely remote applications for a very very long time now. For most users and most applications there is no difference in functionality between remote and local applications.
Were as X11 will never be able to accomplish that unless the computer is sitting in the room next to you. Nomachine and similar tech can speed it up, but that isn't really X11 is it?
"I can pretty much always run the graphical program locally instead"
Then why do you need a remote desktop? This is a really strange comment, because you shouldn't ever care whether the window manager is local or remote (as with XDMCP) - the only thing that should matter is whether the apps are local or remote. Whatever it is you're doing with apps on a remote desktop can be done better by simply displaying the app remotely on your own desktop.
What exactly is the use case for needing to run a second window manager remotely? It's such a strange thing to say that you need.
If you mean connect remotely to a desktop that someone else is using on another machine, yes that is indeed a different use case.
With the advent of GPU, resolution, complexity of a scene all increased several times, making the problem essentially a completely different one than back in the XMotif days.
Think about video streaming, 3d acceleration, sound input and output.
Then whereas you previously had only a handful of vendors to coerce into agreement, now you have a multitude of individuals that are going to complain for every change.
Sadly things moved so quickly that when the X based terminals were new, people where quite excited to use them. However over the 5 years we used them they got noticeably less usable each year. We ended up replacing them with some diskless linux boxes that could run a 24 bit color window manager and browser locally (fast scrolling and window moving) and ran heavy graphical apps remotely over X11, things like Mathematica, Maple, and Matlab. The lab were suddenly much more in demand, and people hugely preferred them over the Mac and Window based labs students had access to. It was a nice mix of offloading servers (by running X11, window manager, and browsers locally) and offloading clients (by running memory intensive software on the server). People seemed to love the low latency keyboard, scrolling, and browsing. Waiting even a few seconds for Mathematica to churn through a notebook of forumulas and rendering was much easier with a responsive desktop. The diskless linux boxes were easy to admin, reliable, and quiet.
Basically browsing is hugely more data intensive than the era of X based terminals, even just scrolling animated windows is tough. Things like a full screen video at 4k was not even under consideration. At the same time people's expectations on performance, latency, and visual richness have increased to the point where X based terminals no longer make sense. Even fast 64 core servers with fast 8 core clients networked over switched GigE gives remote X11 a VERY poor experience these days. Try remote firefox over X11 sometime, it's painful.
I remember using X to run applications from half way across North America about 20 years ago. To be specific, I remember using it to do image editing in Gimp. Performance was great. Heck, I even used it over dial-up connections to my university. For some X applications performance was fine, though I was clearly using it for less demanding software.
Of course, expectations have changed. Microsoft has acknowledged this by continuing to improve upon Remote Desktop. I love and use the feature, even though I cannot stand Windows. While I use a couple of X applications over the network, for the most part I don't even bother. It's finicky to get working. Even when the fiddly bits are set up properly, there is no guarantee the software will work.
ssh -Y remote-host
...
% x-application-name
In essence, a good remote desktop software will use video encoding/decoding (h264/265 for both ways being very fast) to encode captured frames of the desktop, and a good transport protocol over the network with good tuning parameters to achieve low latency (which is what mine does). I believe this is what NoMachine and Parsec do and why they are so good (along with NICE DCV). From my work I've found that video processing libraries/techniques are extremely poorly documented (think the libav* family of libraries), which makes it a very difficult segment to conquer because of what I perceive as honestly massive gatekeeping (or by Hanlon's razor perhaps laziness). There's nothing impossible about making a remote desktop software (I can say this since I'm doing it right now) but I can say it's harder than it has to be.
I was able to use my home computer lag-free at my highschool when it was at home sitting behind a shitty ADSL connection. Later I used it at college with my computer at the dorm with a 100k/sec upload cap (enforced to discourage student file sharing). It pulled some dirty tricks with X forwarding, caching pixmaps, and jpegging the hell out of the individual elements, but it really felt like the computer I was using was right there.
Its better than the Windows client because it just works as another desktop in the Mac OS, with no bar at the top, and you can jump in to and out of various remote session quickly just by switching desktops with Cmd+left or right arrows. Its a really simple, nice to use implementation.
For low bandwidth/high latency links, RDP easily wins.
They do, but the paid version of NoMachine has?/had? a mode called X11 vector graphics explained better by NXDev here [0]. I've used it from 2016 until 2021 and for classic applications (ie apps not requiring a GPU) is incredibly fast. To the point that I used to forget i was working remotely.
Glad someone mentioned it. I wondered if NX was still a thing...
fast
secure (over ssh)
NoMachine blows past RDP every day of the week and twice on Sundays.
First, the two most common DEs, Gnome and KDE, use X compositing by default. This is very bad for VNC. You want to turn that off. Unfortunately you can't with Gnome, which is sad. You can turn off compositing in KDE, and that's one reason I've preferred KDE for years. Other DEs can also forego compositing.
Second, turn off all encryption between the VNC client and server. No SSH-ing, no build-in VNC encryption. Nothing. Ignore the nag warning about the lack of encryption some VNC clients hit you with.
Third, no VNC compression. You're on a LAN and you don't need it or the lag it adds.
Forth, don't "share" the VNC session with the remote host's desktop. Use the vncserver headless X server. Every "shared" VNC system (where the desktop appears both local and remote) I've encountered is laggy.
Fifth, use a fast VNC client. RealVNC's VNC Viewer is excellent.
Sixth, do not scale. Ensure your vncserver's resolution matches your VNC's client size exactly.
Seventh, tune your DE to remove whatever animations or alpha effects exist.
Eighth, no wifi. Ethernet only between VNC server and client. Wifi is awful for this.
Ninth, use decent ethernet gear. Some NICs are low end and impose more latency. Likewise, low cost switches are bad news as well.
Do these things and your VNC session will be difficult to distinguish from a local DE. If you're using gigabit or faster LAN you'll be able to play video through VNC reasonably well.
I think you just proved that VNC isn't a good replacement for RDP.
One benefit of using VNC is the lack of glitches. I've been down every road; nomachine, various commercial and open source X servers, xrdp, all of it. They all have glitches; sizing problems, decoration problems, font problems, keyboard state problems, pointer problems, you name it. VNC (operated as I've described above) doesn't; everything is correct, all of the time.
I've had good luck with tigervnc in the past. My raspberry pi 4 had trouble pulling 4k video, but whatever.
Most of the vnc latency comes from unoptimized compression (like not using SSE for jpeg, etc), or poor default settings.
There are also remote desktop protocols that rely on GPU accelerated compression (mostly for gaming and 3d work). Those are mostly fine for light 3d shooters, etc. Sometimes I even watch YouTube videos over them with a 10-20mbit, 40ms internet connection. (I didn't bother measuring network usage for that; 20mbit is an upper bound.)
Is compression really bad? In instances like file system, sometimes it may even be faster to enable compression as disk IO is slower than computational time.
And you're telling we need desktop to desktop to make it work good and what kind of NIC can't handle enough bandwidth for VNC? You sound like we're playing a next gen VR game.
Compression noticeably adds latency. You see that easily when scrolling windows; it's not difficult to detect at all. The intent is to get minimum latency; I use these remote DEs all day and latency creates fatigue. If you're truly remote with limited bandwidth then compression will clearly have value.
> and what kind of NIC can't handle enough bandwidth for VNC
Today, integrated NICs are great, but not long ago some of these were poor and roundtrip latency was as high as 100 us or more. I could see the difference just holding the space bar and watching a terminal cursor move. If you really want a nice experience use a decent NIC; nothing crazy, just not low end integrated stuff that's barely more than a PHY and relies almost entirely on the CPU.
Latency is the thing I've worked to reduce so my remote desktops feel as local as possible. Every incremental change I've made has been noticeable; 2.5Gb/s is slightly better than 1 Gb/s when playing video, for example; something I noticed recently after upgrading the NIC on one remote host.
Personally, I've used stuff like Steam in-home streaming and Parsec for remote desktop access. They're more meant for game streaming but they handle normal applications just fine and they run on pretty much any platform I can think of. As an added bonus, there's something nice about the idea of picking up a cheap second hand Steam Link and using it as a thin client for your PC.
Don't know about macOS, though.
It's quite usable graphically even with such channel. Of course, running graphically intense programs or remote video would not be practical, but spreadsheets ok.
I wouldn't expect too much from a DSL link but at a low render resolution (<720p) even video should be doable with the right tweaks. Quality won't be great, but those stupid video ads shouldn't lag out a browser session for example.
If xrdp or equivalent don't support those extensions, I see an opportunity for distro makers there. Linux distributions (and others) have been reliant on VNC for way too long in my opinion and the only somewhat supported alternatives with more than one implementation aren't exactly built for this purpose, sadly.
You can screen share a remote mac very efficiently, drag and drop files, use keystrokes such as modifier-plus-key in a sane way, and more.
VNC Linux/Windows > MacOS is so incredibly painful and unusable:
Multimonitor: No. Correct scaling: No. Copypaste: No. Thats only some of the bigger problems.
I wonder what Apple is doing differently with their VNC connection.
I use it over ssh myself.
for example, if I have a machine call rem:
Host rem
Hostname 10.1.2.3
User foo
IdentitiesOnly yes
IdentityFile ~/ssh/id_rem
# rem screen shares on port 5900 locally
# this forwards rem:5900 to this machine:5903
LocalForward 5903 localhost:5900
ssh rem
choose Connection -> New and enter: localhost:5903
when you log in using username/password and you will get a nice remote window on your desktop
The window has lots of nice features. You can drag files from your local desktop and drop them on the remote desktop and they are copied over.
cmd-tab in a screen sharing window works on the remote machine, but move it out of the window and it works on the local machine.
You can copy/paste between apps on the local machine and apps on the remote machine, including rich text stuff.
There is probably lots more I don't remember or haven't discovered.
(I'm using it for linux to linux.)
https://news.ycombinator.com/item?id=32239025 - RustDesk – Open-source TeamViewer alternative
I support my in-laws and my daughters running Linux on their laptops and it worked fine and was pretty quick.
By the way -- we are all running various fairly recent versions of Linux Mint with the MATE desktop. The oldest being mine: [Release Linux Mint 19.3 Tricia 64-bit].
1. There is some trade off of latency for bandwidth: it may take more time to figure out a small change to send over the network. Looking at api use from eg X may help with old apps that make small updates but more modern apps (or even modern fonts) which just render to gpu buffers and composite are less amenable to this. Very modern apps that use special apis to do lower latency scrolling/resize may be a little better.
3. A lot of the time for Linux the solution is to use ssh and terminal apps as they tend to make smaller updates and require less bandwidth. You can also try mosh to compensate for high latency connections. Text editors can work ok in terminals, especially fancy modern ones with eg mouse support. And for web things you can do set up a socks proxy over ssh which I think can work for a lot of apps which are really just web sites. So this may be part of the reason: fewer people see Remote Desktop as necessary.
4. I’ve had reasonable success with xrdp on the server and a windows client. One needed to select 32-but colour to get a better protocol version and turning off double-buffering in some apps (eg emacs) helped. But that was over a wired high bandwidth low latency connection.
"Real" terminal apps (i.e. command line utilities) are fine the way they are and you wouldn't use them any differently locally. They don't even need to care if stdout is a tty, and they reap all the benefits from a CLI because you can script them and pipe them into grep/awk/etc...
But as soon as we skid into ncurses territory, we're stuck with ANSI terminal codes to make some sort of graphical UI. Those apps don't benefit from being in a terminal (e.g. you can't grep htop output), and there's obviously some desire to make something visually appealing. Using in-band magic escape codes from the 1970s with severely limited functionality for that is just a workaround for the lack of a standard remote desktop protocol that actually works, is reasonably efficient and SSH-friendly.
Sure, the fact that you can make ncurses apps feeds back into complacency with the status quo, but that's always true. The enemy of great is good enough.
The other alternative is making a web UI, which in principle has the right architecture (run the UI on the client side and only push/pull meaningful data to/from the server), but unfortunately that's tied to HTTP(s), which isn't exactly SSH-friendly. What we'd need is a transport-agnostic version of HTTP that can be given a socket and communicate with the server through that without demanding to know how to open more connections to the server and demanding that those connections be made through AF_INET or AF_INET6 sockets.
So again, some server software is implemented as a web UI (like CUPS), but that's a workaround for the lack of something more straightforward that's also a de-facto standard.
X2Go is also pretty good IIRC.
I used NoMachine at work a few jobs ago, but I didn't like how it required a weird dedicated unix user for itself. I don't know why they needed that (maybe so that they could multiplex multiple users over a single port or something like that?), but I never understood why it didn't just run as my own user. It was fast, I'll give it that.
For anyone unfamiliar, it's similar to ssh -X but with modern compression, so it works well even with reduced bandwidth.
If you want, you can also use it to view an entire desktop but I find it much more comfortable to have the windows on the remote computer act as windows on my local computer.
Some years ago I made a WYSIWYG customisation utility to configure not just Xrdp sessions, but also the look and feel of the Xrdp login manager : https://scarygliders.net/xrdpconfigurator/ , https://github.com/scarygliders/XRDPConfigurator
I've not done anything to it for years - lost interest in the whole thing - so it definitely needs an update to more modern versions of Python, PySide, whatever.
Pull requests welcome, in case anyone is ever interested (it's not a sexy project I suppose).
But I was particularly proud of the login screen emulator for the WYSIWYG part of it :)
That grad student and I argued about many things, one of which was the relative merits of X windows and RDP and he was right about that one. RDP was written with the X Windows experience in mind and it performs much better. Compressors for the X protocol were made but they did’t address the high latency nature of the protocol.
X is distinctly asynchronous. You don't send the server a command and then wait till it ack's that before doing something else. The actual delay between the client sending the command and the result appearing on the server's display can be extremely fast (dependent mostly on network performance), and by most definitions that is a "low latency" system. However, if the app on the client needs more synchronous behavior from the server, that's when you start to see things slow down and demonstrate "high latency"
Remote X11 worked well in the past. It's possible to latency-optimize software for it, but it's not common anymore.
It’s pretty awesome, any device with a x264 decoder chip can be a performant client.
Teamviewer runs great in Wine
For example, one "remote desktop" that has become popular lately is called Wireguard. You connect, open the spreadsheet stored on the office network drive and print it to either the printer in the office on to the printer sitting next to you.
Many people would say that is sooo much better than RDP. That is not Windows thinking. That is Unix thinking--you know, Mac/Linux. (And BSD and most everybody else in the world)
So, to say it differently, Mac/Linux people often solve problems a different way, so they use different tools. Why don't laser printers come with whiteout toner?
A remote desktop does the CPU-intensive computation on the remote side, not the local side. A tunnel like Wireguard or SSH does the computation on the local side, foz GUI programs that don't run in a terminal.
Now, quite a lot can be done from a terminal, but some compute-intensive things are better suited to GUI programs. CAD/CAM, for example.
A 4k screen scaled to 1080p, then rescaled on the remote end is very useful.
I don't mind paying for closed source software one bit if I can run it in a sandbox with extremely limited privileges and network access on an opt-in basis.
But a remote desktop solution isn't useful that way. By definition, it has to have all the powers that you have. And for that reason, it's one of a very small number of categories of software for which closed source is simply a non-starter.
On local networks I've had good luck tunneling X, and it's even worked well running lightweight programs remote over a VPN in a pinch.
For "real" remote connections through the internet, x2go has been pretty good. At a previous job I used Remmina (an RDP client) to connect to Windows machines, and X2Go for Linux machines, and they felt about the same to me.
It really depends far more on network speed than anything else.
No idea about the performances of a remote Linux desktop because I connect to remote machines with ssh and use only the command line. It's maybe 25 years since I run remote X11 applications to my local server.
There are other apps like NoMachine and TeamViewer. I never used them with a remote Mac.
I've been using the nightly branch for 6 or 7 years now and have rarely ran into issues. In fact our entire company runs nightly due to using the latest bastions and gateways servers that sometimes the version in the main repository do not support yet.
Open Source and development is lead by an Intel employee. I use Arch (btw) exclusively on my personal gear and I'm a first class citizen along with pretty much everything. The Windows binaries are signed too, which is nice. It also fully supports Intel AMT (vPro) which is probably why it is supported by Intel.
You can auth with say MS Azure (documented config required) so you simply click on the MS logo instead of filling in username and password and if you have an Azure cookie you go straight in or you go through the usual MS sign in thing. There are several more auth/auth mechs.
There is an agent install required and my Ansible playbook for it is roughly 10 lines long so rather simple.
Cendio Thinlinc https://www.cendio.com/thinlinc/what-is-thinlinc
Also you can use game streaming technologies such as Steam remote play over layer2 VPN and hack it to stream your desktop. Since game streaming uses mpeg4 like video compression technology and is built for low latency the lag will be less and video quality good.
Steam streaming https://store.steampowered.com/streaming/
You need a Layer2Vpn to use steam streaming Freelan layer 2 VPN https://www.freelan.org/
It’s more efficient to use a remote shell than to pipe a constant stream of screenshots at video rates, to say nothing about latencies and mousing.
Draw commands would require a uniform windowing solution for all clients.
I cannot speak for why Apple doesn’t make such a product.
I think they do; there are a lot of comments in this thread about MacOS having some sort of remote desktop built in, which sounds like a tweaked VNC implementation that actually works well when you're just connecting from one Mac to another.
Xwindows used to have the same advantage, but lost it for most modern applications (i.e. ones written in GTK or Qt, which pre-rasterize almost everything for simplified cross-platform compatibility). Nowadays, unless you restrict yourself to classic X applications, X forwarding is going to be a slower, dumber, version of VNC.
Mac has so many fades & animations that, raster or command, it will probably always be slower.
I think the direction to go, being compute/GPU nowadays much more powerful and even in the same chip (and bandwidth), is to just remote the framebuffer or the video output built on the source machine, with realtime hardware assistance. No primitives, no API... just pixels, so both world can evolve without being in lockstep.
PCoIP is proprietary but the basic philosophy is pretty sounding ("graceful degradation" etc., I've used it even across WANs and the experience was pretty good).
Amazon AWS is using it to stream its remote cloud desktops.
Two of my three monitors run fullscreen RDP to my work laptop. I run Slack and Teams on the other one (on my personal PC) because audio/video over RDP is the one thing that doesn't work well. I can even copy/paste images across.
At one point I tried using a dock. It required me to physically switch the cable as well as switch inputs on one monitor (to still connect to my PC's GPU). Though a multi-hundred-dollar KVM could have "solved" this, it was still occasionally glitchy, comparatively slow to switch, and, frankly, just not as convenient. Doing it 100% software is just better.
I wish I could get the same experience doing this to a linux or mac system. In my experience, remote macOS over VNC is a punishingly bad experience, while RDP to a system even sitting physically next to the mac (same internet/VPN/LAN connection) is entirely usable.
https://www.rfc-editor.org/rfc/rfc6143.html
I've only seen very good performance using the built-in VNC client/server for macOS. You can try it out by turning on remote sharing and doing this from the terminal:
`open vnc://<host>:5900`
Case in point - scrcpy, remote "desktop" to access Android from Linux/Mac/PC. Very responsive, including during fancy animations, playing video, games, etc.
And crucially: none of this harms the performance of my local session. I don't have any background daemons or special modes running, I'm not in a "virtual remote session" when working locally. It adapts resolution and screen sizes when I switch to remote consoles.
Everything just works really well, whereas the same is not remotely true on Linux. The best in class - x2go (NoMachine variant) can't do this. My local session can't become a resizeable remote session, it just becomes a slow screen grab of it, and doesn't allow me to lock the remote session when I log in, or kick off the remote session when I log back on.
If anyone knows how or what can get this experience to Linux, it's IMO not only something I greatly desire - it's vital.
I've found the SPICE protocol using the QXL driver with some compression settings tweaks gives the best performance. The latency is better than VNC, but video/graphics intensive screens are still a problem unfortunately.
I use it to connect to the console of a VM over VPN for Linux development currently.
https://github.com/neutrinolabs/xorgxrdp
I love it. It only works with X11, not with Wayland. Wayland refuses to add a protocol command for "blit this image to this surface" (would be ~20 bytes). That is the critical feature your protocol must have in order to get good RDP performance. Windows GDI has it.
To get good, responsive RDP you need to be able to send an image across the network once, and then be able to blit it to on-screen surfaces without having to upload the whole image again.
Windows GDI has this. X11 has this. That's why they're fast.
The only real other uses for it that I can think of would be if I were working with graphics/video with files so large that transferring them would be annoying, or cross-platform access, like working on a remote Windows installation from a Linux machine. But for that, there seem to be multiple programs on Linux that implement RDP well enough for MS itself to recommend them.
It has also become a very efficient protocol on the client side: only last week I set up a dedicated terminal using a 512MB Raspberry Pi 3A (https://taoofmac.com/space/blog/2022/08/14/2030), and I can stream a Fedora desktop to it at 2560x1080 with audio (i.e., good enough to watch windowed video) and very low latency over Wi-Fi.
On the Mac, there is no equivalent because Apple pretty much neglected anything to do with remote displays — Apple Remote Desktop is a variation of the VNC protocol with extra authentication but no real encoding improvements (and designed to manage Macs in classrooms or small businesses over a LAN), so it completely lacks any real ability to work over real-world remote connections.
There have been a few attempts at jerry-rigging an RDP proxy on top of the built-in Mac VNC server, but I haven’t seen anything working in years. And NoMachine is just plain useless in most scenarios.
(I’ve been using VNC, Citrix and RDP over the past couple of decades and am quite into all the details - I’ve also streamed desktops over H.264 and various multicast setups for electronic signage, so I’ve explored plenty of hacks)
https://support.apple.com/guide/remote-desktop/welcome/mac
https://apps.apple.com/us/app/apple-remote-desktop/id4099073...
None of the options I tried on linux could match this features.
NoMachine did perform well but having the remote computer in the same room I could see it was mirroring the physical monitor and I could type on the keyboard. It does have a feature to make the screen black and lock inputs but then you're unable to log in from physical even if you know the password
Key features:
1. Extremely fast and smooth screen sharing. I've used RDP, I've used VNC, I've used Chrome, I've used Apple's screen sharing. None beat it.
2. Multiple mouse cursors! You can see where your co-workers mouse is, and they can click and interact with your desktop just like you do (if allowed of course). So far this has been the best way to do interactive code review sessions and even some pair programming.
3. Smooth animations. I originally started using it (back when it was called USE Together) because I wanted to do a presentation remotely that would show smooth 60fps animations from an app I was working on. It was the only one that could do it.
I never used it on Linux however.
This leaves multiple fragmented camps of GUI to target, increasing the technical debt before you can get anything done. Wayland was a step forward, but overall 20 years too late. This stuff isn't rocket science; if something hasn't been done its a structural issue that needs to be addressed but the project maintainers of the projects that you would need to target don't see it that way.
Why should someone that puts effort in to a project like this be forced into a dovetailed management strategy that is doomed to maintainability failure as a 1 bus factor project.
I used that 'protocol' to build this: https://allmydesktops.com/
NX (the protocol it uses) had a novel way of only updating pixels that were changed and tunnels through ssh for security. Although if you're curious on the technicals look them up; my knowledge of it's got to be 20 years old at this point.
Is there any free / open source solution for Mac? Parsec is really nice. So is JumpDesktop. But running a closed source is a little jittery because no one knows what it could do and capable of.
The workflow does require some security and privacy since it is not like gaming. Sometimes accessing a sensitive file or a document across multiple networks requires the opensource software's trust which can never be provided by any closed source application.
Some of the mentioned solutions like RustDesk is really good and it is open source and can be self hosted (it does win on many areas naturally!), but it still lacks the performant part to the likes of Parsec or JumpDesktop or similar high performance RDP solutions. Anydesk is again closed source.
I've settled on Steam Link for remote desktop on Linux. It still has one big issue for me: the cursor rendered by Steam jumps around weirdly at the edges of windows. I would love to solve that problem. However, apart from that, it flawlessly transmits video and audio in a way that Just Works.
I just wish it was packaged as a standalone solution.
For most cases you just need a GPU or some hardware video encoder (H264/H265/VP9/AV1, etc.) that can work in real time. It's not the most efficient in terms of bandwidth, of course, but if you have a decent connection to your remote peer it's the most straightforward way to accomplish this on any system.
I haven't tried Parsec personally but from their website description and screenshots, it looks like they're taking this approach and I bet it works great.
For my own gaming I used Parsec for a long time, which does stream pixels but has pretty impressive variable rate compression.
- Teradici is the best I’ve used (hardware and software options)
- HP remote graphics licenses come with some Linux workstations
- Amazon NICE DCV is used in AWS Workspaces (disclaimer I work for AWS)
- Thinlinc is high performance but no GPU acceleration or audio the last time I used it
There are others but those are the ones I’ve used the most and recommend
For macOS, Apple's Screen Sharing is pretty good, using some video compression and diffs to render the frames rather than vanilla VNC.
Sound doesn't yet work on macOS (word is coming soon) but I found it otherwise the best in the space. Also supports Linux and Windows.
Right then and there, the choice flipped the other way: instead of taking the management approach to remote computing they made management go the MDM route, and made remote computing more of an application-specific detail; if you need something 'remote', it's probably just data so remote data access could cover that. If you need a piece of software, the idea was that you'd simply run it locally instead of remotely over a stream, and if you need something specific to the remote location (i.e. the network) you'd use a VPN connection.
The biggest benefits of terminal-style computing is that you can lock away special software on a server or use computing resources that aren't available locally. That second part was something Apple probably never wanted to have to deal with, either you get the 'big fat expensive machine' for your heavy workload, or you get the Mac mini for your ligher workloads. If you want to have one big machine shared by two people, that wasn't really something they cared about, and you'd just have to buy two of them. This makes sense from their perspective: you buy the machine for a specific task or purpose, and that makes remote computing a bit redundant because you'd have bought the machine that fits your needs.
In a way they are right; nearly every device they make can do the same tasks and only heavy resource eaters really need more hardware than a base configuration can deliver.
For Linux it's different; you can just install an RDP client and server and do the same thing windows does. The only thing you need to do yourself in such a setup is configure the desktop environment so it doesn't do weird things like wobbly window animations over RDP which don't translate well. Microsoft doesn't write RDP clients or servers for Linux, and only has a client for macOS, so not much of a commercially validated option on Linux. There is NoMachine's NX which essentially does what RDP does, and on Linux you'd also not actually transmit the entire application; most of the window chrome can be handled by the local window manager instead, like with X11 forwarding.
https://linuxhint.com/enable-remote-desktop-ubuntu-access-fr...
Mac to Windows is easy with RDP.
But sharing a screen, Linux to Mac or vice versa... I wish you all the best. It's wild to me too.
There are RDP implementations for Linux both client and server. x11rdp, remotedesktop,, etc.
There's also Teradici (HP bought them a few months ago) but that can get pretty costly.
With regards to the Mac, MacOS is BSD-based. BSD UNIX has had that capability and the required software for decades. So ... the capability is there. The software 'app' probably isn't. It would probably only need the installation of several packages.
MacOS is a downgrade from the underlying BSD UNIX that is its foundation.