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.
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.
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.
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.
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.
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 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://
Case in point - scrcpy, remote "desktop" to access Android from Linux/Mac/PC. Very responsive, including during fancy animations, playing video, games, etc.
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.
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.
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.
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...
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.
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/
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/
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.
(I'm using it for linux to linux.)
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.
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.
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.
It’s pretty awesome, any device with a x264 decoder chip can be a performant client.
Teamviewer runs great in Wine
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.
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.
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?