Hacker News Reader

Comment by II2II | Hacker News Reader

The happens to exist bit turns out to be very important. I can login to a machine and run an X client without installing and configuring extra software on the server. If I am using a desktop with X installed (most *ix based systems), there is no extra software to install and configure on that end either. The worse case scenario is the necessity to install an X server on platforms like macOS and Windows.

The same sort of thing can be said for Remote Desktop. If you're using a version of Windows that includes it, it is wonderful to use because it is just there.

Which is better? It depends on how you're using it. I generally prefer Remote Desktop for my use case because it takes care of audio and it is easy to resume sessions. That being said, those features don't matter to me most of the time so X is just as useful.

View on HN

> The same sort of thing can be said for Remote Desktop. If you're using a version of Windows that includes it, it is wonderful to use because it is just there.

Doesn't every Windows include it? I can't remember the last time I used a version of Windows that didn't have it, it must have been 20 years ago.

As far as I can tell, only the client ships with "Home" versions. You need to be running Windows Professional or Windows Server for the actual server.

Right, the shift away from X doesn't mean the death of using GUI apps remotely, it just means moving to a Remote Desktop model instead of telling apps that their render target is your X server through a tunnel.

Could you flesh this out a bit? What is the official Wayland model for doing "Remote Desktop"?

I hesitate to call it an official model but the short version of the current direction is that the compositor acts as the glue -- providing the final rendered scene and the final merged audio stream to the client over some protocol (like VNC but doesn't have to be) and providing inputs and events to itself and the client applications.

How all of this works on the backend is a combination of PipeWire to multiplex video sources and PulseAudio to multiplex audio sources.

There's nothing outright preventing something like X forwarding and https://mstoeckl.com/notes/gsoc/blog.html is a really cool project that makes it work.

From that author:

> The main difficulty in producing such a tool is that Wayland protocol messages primarily include control information, and the large data transfers of graphical applications are implemented through shared memory. waypipe must then identify and serialize changes to the shared memory buffers into messages to be transferred over a socket.

What if I don't want a remote desktop though? 99% of the time I only want a the remote application I am interested in to seamlessly display on my screen, why do I have to bring along a full desktop?

Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.

What implementation of a remote desktop model currently exists for Wayland?

The "big two" have implementations. Definitely not mature but it's getting there.

https://wiki.gnome.org/Projects/Mutter/RemoteDesktop

https://docs.kde.org/trunk5/en/kdenetwork/krfb/krfb-configur...

You most likely won't see an implementation "for Wayland" because that's like asking for a websocket implementation "for HTTP" the actual compositors that speak Wayland need to implement remote desktop capabilities and then expose an API for managing remote desktop sessions (org.freedesktop.portal.RemoteDesktop) to programs that want to leverage it.

I haven't tried it, but there's also this one for wlroots-based compositors (eg. sway): https://github.com/any1/wayvnc

Reply on news.ycombinator.com