Current prerelease is 1.2.5
1.2.4 is the first to introduce experimental Wayland support. Especially on KDE Plasma there are supposed to be some issues.
Lets test!
Why?
Regular RDP/VNC programs are hard to use in real scenarios, as they rely on IP addresses. RustDesk is easier as it uses a Rendezvouz server that can also be selfhostet or reimplemented.
RustDesk is really good but I can’t get certain decisions / limitations they have. For absolutely no reason, this, only seems to work under Windows… or are they trying to push people into the Pro Server / build your own which will ultimately require you to buy a license for their software (okay reasonable) AND developer accounts so you can sign macOS binaries (not okay).
They also document scripts to bootstrap clients on other OSses. And I don’t think you need Pro to build rustdesk yourself - they even document the process.
To be fair, the APGL requires to publish code that is compilable. So giving instructions is pretty relevant for more complex projects.
They don’t define what ‘compilable’ means though (among many other things), and it’s pretty easy to come up with several different definitions of it that not everyone will agree with.
The one big thing they do hide behind Pro though, is authentication for the server side. With the free version, if your server is open to the internet, then anyone who knows the IP can use it to relay their clients as well.
They still need to know the key. If you publicly distribute your config, that’s a problem. But IMO one even the pro version couldn’t solve.
The point is that under Windows you can change the App name to set credentials and other settings like this:
rustdesk-host=mydomain.tld,key=eiu5pzFYlr5nY9i9yJp9smzzLnvx4XNX7O3SaNhkWS8=.exeBut under macOS you can’t do it… just because they don’t want to.
The apps are bundled completely differently on OSX and Linux. It’s technically not possible to do the same thing there. Also this is not a free/paid limitation at all.
They could maybe build a packaging tool that can customize the binaries (adding data to the PE executable in Windows and maybe a property file in OSX and Linux); but that’s quite some effort for not much gain.
Qt actually ships platform tools that modify binaries to change the library search paths.
I said it’s possible, just much more effort than the current solution which only requires reading and and parsing the process name on startup.
Under macOS it’s trivial to change the name of the application package without messing with other aspects of the packaging.
If it’s so easy to implement, go ahead and open a PR. The community will be thankful.
Are you affiliated with the project in any official way?
If so, thank you for such a nice product.
No but I agree
I hope to God that RustDesk doesn’t get corrupted or enshitified because I absolutely love it.
Been using it for remote assistance at my workplace for about a year now and it’s been almost flawless. By far the most responsive and easy to use remote access solution I’ve used, (and I’ve used a lot.)
I use it with my family across the country to do remote support for their family computer too. It is small, lightweight, fast, handles multiple screens like a charm, and I don’t think I’ve ever had connection issues, even when on really slow network connections.
I’ve been using it on Wayland for months. But now that I think about it my key presses never reached the other side. Mouse works fine though.
Looking forward to the update!
Not recommending against RustDesk - it is a very cool project - but regarding the “Why?”, you could use a VPN or something like Tailscale which has MagicDNS that’ll resolve hostnames of computers to their local IP address. You can use this with GNOME’s RDP server to remote in from another device pretty easily.
Nope, you don’t get it.
They have clients for basically every platform. That means you can control your Windows desktop from your Android phone, or use your Linux Desktop to control your iPhone… the platform does not matter. It works on any device in any direction.
Also, you don’t have to expose it to WAN. You can run it locally and use Wireguard the same way to access your LAN… so why even mention something like Tailscale?
Do you have a guide for that? And tailscale is proprietary isnt it?
Only the Tailscale pairing server is proprietary but there’s a FOSS self-hostable alternative called Headscale.
The Tailscale clients are FOSS.
There isn’t much of a guide, you install the Tailscale clients and make an account on their website. After you enroll your devices to the account with a code they’ll be able to access each other via private IPs on an encrypted network based on WireGuard.
You can connect among devices with unsecured protocols like VNC because they’ll be inside the encrypted network. And this works with any app and any protocol not just remote desktop — you can use Syncthing, access files, access any services you want securely etc.
Sounds pretty damn awesome, need to try it.
And to add to this, if you want another overlay network solution like Tailscale that is fully Open source, Netbird is something to check out.
Lawrence Systems has some vids on their product, fully self-hostable 1st party control plane and Foss clients. Newer, smaller, not as well supported as Tailscale, but solid enough for homelabs and small biz solutions from what I’ve seen/read.
I’ve messed with both and each has their own strengths. Both solutions are really awesome though. Unless you need really high network performance, I feel like overlay networks are the way to go. Soooo much easier to setup and maintain than traditional ipsec tunnels or even OpenVPN firewall configs and manual routes.
Really nice! uBlue has Tailscale preinstalled, but I now switched to their simpler variant. I will try Nerbird!
this kind of software is mostly used for tech support, so your option is too hard to setup
