RustDesk – Open-source TeamViewer alternative
github.com
github.com
I see that RustDesk is licensed AGPL 3.0. At the same time the GUI component (Sciter - https://www.sciter.com) is proprietary software with it's own non-compatible license (https://github.com/c-smile/sciter-sdk/blob/524a90ef7eab16575...).
Was the intention to use something like LGPL to stand on the shoulders of the external libraries or was the choice of AGPL just a hopeful goal with licensing issues to be resolved in the future?
Works really, really well and doesn't try to wrongfully block me for 'commercial usage' like Teamviewer does.
Since their laptop is usually on WiFi behind an ISP-provided router/modem combo this is ideal. Also don't need to force a static IP on the network so the port forwarding rules align properly.
As I say, we're in different countries so this is very handy, it "just works".
Also is secure as nobody can jump onto the virtual network without explicit whitelisting on ZeroTier's Web UI. You have to login (with 2FA) and click a checkbox to allow access if anyone wants to join.
Disclaimer: I didn't test this, so no guarantee it's 100% secure. Specifying no-pty or Command in the authorized_keys files doesn't seem enough, though.
[1] https://askubuntu.com/questions/48129/how-to-create-a-restri... Check the accepted answer.
But the downside is that they had downgraded everyone in the free tier to only 1 hosted network, which is sad since now I can't do different groups.
I used to have a group for each circle of friends so that we can play LAN games together and now I need to ask one of them from each group to set a network themselves for me to join.
Self hosting (Moon instances) introduced basically nothing since our network wasn't super reliable. With their current pricing it wasn't that useful to us so I'm now in a love-hate relationship with Zerotier.
Looking at their pricing page the limit is listed as 25 networks (didn't this used to be 50?).
Partial support has already been added: https://github.com/rustdesk/rustdesk/pull/932
I wish I could switch to Wayland but the amount of gotchas is so huge that if I want every app to work as expected then X11 is still the only way to go.
I have personally a bug when sway does not return from sleep mode, sometimes randomly, and I have to physically power off the pc. It just shows black screen with backlight on.
I guess the issue is on AMD drivers, but it is likely that it will never be fixed. I have no idea how driver bug can cause this on Wayland but not be an issue elsewhere.
https://mastransky.wordpress.com/2020/06/03/firefox-on-fedor...
Also, enabled by default with Mesa in these days
https://linuxstoney.com/firefox-has-hardware-video-accelerat...
Wayland is a wip (a number of things are being worked on right now that have never even been fathomed for x11) and it's already a significantly better experience in countless ways over x11.
However since Wayland (or at last KDE's Wayland implementation) doesn't provide any functionality for changing video modes, the bug isn't triggered when running KDE with Wayland as the latter forces games to use whatever video mode the desktop uses.
Of course that means that games that do not support 1280x720 wont work at all, but that's minor details, about as important as using a lower resolution to get better framerates from the Atom iGPU the device has :-P
(ok, actually might be possible by using gamescope[1], which runs its own Wayland+XWayland compositor inside an SDL window that you can also force to use a specific resolution - again no resolution changes are supported and that uses wlroots - that can be scaled to arbitrary outputs and if the SDL you're using has a Wayland backend to avoid going through the desktop's Wayland compositor's XWayland layer then you may not get that much lag at all - though not sure if there'd be enough memory left for the game after all that :-P)
On capable hardware (which your's probably isn't, not sure of Intel HD 405 capabilities), it is not a problem. The compositor can allocate a surface that corresponds to a given resolution (higher or lower than physical one, doesn't matter), the application renders its output at its preferred resolution and then compositor scales that buffer (using the output encoder's scaler, not GPU!) to physical output, effectively emulating that resolution.
Well, at least Mutter is capable of doing this, not sure of wlroots.
I have learned my lesson, and will NEVER buy another nvidia product, not worth the trouble.
FYI: Nvidia published open-source GPU Kernel modules couple months ago. Maybe there is a brighter future ahead.
https://developer.nvidia.com/blog/nvidia-releases-open-sourc...
https://github.com/NVIDIA/open-gpu-kernel-modules/issues/161 https://gitlab.gnome.org/GNOME/mutter/-/issues/2166 https://www.reddit.com/r/kde/comments/vgqyv2/wayland_nvidia_... https://gitlab.gnome.org/GNOME/mutter/-/issues/1891 https://forums.developer.nvidia.com/t/external-monitor-doesn...
Maybe there's some edgecase that I haven't hit that it fixes?
Unless your displays are mixed DPI.
Wayland works much better in this scenario.
...right?!
But yeah, if you want to use scale some ancient out of date Electron app, you might have to use Xwayland it might look bad under some compositors. Not really the end of the world. You can even easily use OBS to screen share to those apps these days.
We did some stupid things before, especially the Wayland "Fix it" button, no excuse, we have removed it, and been working hard to make Wayland support work. https://github.com/rustdesk/rustdesk/pull/932
We are also removing Sciter, rewriting the UI with Flutter, https://github.com/rustdesk/rustdesk/tree/flutter_desktop. But Flutter does not support 32-bit Windows, we have to keep Sciter for 32-bit Windows version.
As an open source project, we only have very limit bandwidth for you, the connection is not reliable sometime if you use our public servers. That's why we encourage the selfhost, and open source the server https://github.com/rustdesk/rustdesk-server. We are attempting to improve the bandwidth, https://github.com/rustdesk/rustdesk/discussions/1026.
Here is a good video for selfhost which can help you. https://www.youtube.com/watch?v=9nzHm3xGz2I&t=1032s
We hope more contributors can join us to make it better.
Here is our milestones: https://github.com/rustdesk/rustdesk/discussions/918
I do not know why @Technetium said "impossible to communicate", appologize if I made you not happy before. I just lost patience sometimes, it is really not an easy job to maintain an open source project like RustDesk. We communiated very well with RustDesk Server contributor, https://github.com/rustdesk/rustdesk-server/issues/36.
This makes me a little worried about non-memory management security bugs. Rust is definitely helpful in eliminating one major category of bugs, but the belief that this is sufficient for users to not have to worry about security is misguided.
For example, in GC'd/RC'd languages, if we have several UserAccount instances and a bunch of long-running operations on them, any particular long-running operation will just hold a reference to the UserAccount itself and modify it at will without any confusion.
In Rust, the borrow checker often doesn't let us hold a reference from a long-running operation in practice, so we work around it by putting all UserAccount instances into a Vec<UserAccount>, and have our long-running operations refer to it via an index. However, we might erase and re-use a spot in that Vec, meaning the index now refers to some other UserAccount.
If the operation uses that "dangling index", it can lead to leaking sensitive data to the wrong users, or data loss.
When using Rust, one has to use discipline to avoid this bug: use IDs into a hash map, or generational indices, or Rc<RefCell<T>>. Each has its own performance hit, but that hit can be worth it to prevent privacy bugs.
In the GC'd/RC'd language, this would still be a bug, but it wouldn't cause any mixups between different users' data.
I'm not saying we should always use GC'd or RC'd languages for privacy-sensitive purposes, but one should be aware of the particular shortcomings of their tools and have proper practices and oversight in place to mitigate them.
The perf hit of generational indices/arenas is minimal, and the cost of Rc<RefCell<T>> is still lower than complex GCs without JIT.
> In the GC'd/RC'd language, this would still be a bug, but it wouldn't cause any mixups between different users' data.
I've seen that exact bug in systems written in all kinds of languages.
And for what is worth, keeping a Vec<UserAccount> in memory only works on single instance services, anything beyond that and you'd have to deal with cache invalidation as well.
The most obvious/naive solution along the lines you spelled out (in rust but really for any language) would be a hash map of ids/values, otherwise Rc and maybe some weak references.
I think we can do better than saying that indexes into Vecs are "non-idiomatic" in applications... such advice could remove much of Rust's performance advantage, and make folks wonder why we're not just using GC.
Perhaps we could instead say that if one finds themselves reusing slots in a Vec, they should instead use generational indices, hash maps, or Rc<RefCell<T>>, depending on their use case and what kind of performance overhead they'd prefer.
Rust's focus on making things explicit has a tendency to make programmers want to remove every clone and allocation and make a mess of lifetimes and references in the process.
Just use Arc<Mutex<UserAccount>>. Clone freely. Box things. It makes programming so much easier, and performance will still match or exceed other languages. GC languages do the same things, but implicitly.
Except the confusion of data races and having multiple concurrent writers more generally. Not a hypothetical: I've worked in a large C# code base where other people had decided it was fine to just pass a bunch of references around to different long running processes, and sure enough, they ended up stomping over each other's assumptions in really dangerous ways.
Unless of course you're actually controlling access to the data somehow (mutex / read/write lock), in which case you can just use _exactly the same pattern_ in Rust... so this whole thing seems like a bit of a red herring.
> [...] so we work around it by putting all UserAccount instances into a Vec<UserAccount> [...]
No, "we" don't. That's one particular (bad) pattern you could choose, and I wouldn't even say it's an obvious alternative. If in your hypothetical alternative programming language you would have just kept a reference to the data (via GC or ref counting, as you said) then why not do exactly the same thing? `Arc` is a thing. It works just fine.
This sounds like a case of trying to come up with convoluted solutions to simple problems and thereby doing something unnecessarily bad that nobody made you do.
Rust certainly has its warts... but this isn't one of them. Rust doesn't make you do what you're describing, and you could equally choose to do the same bad design in your preferred GC language.
We agree it's not the best solution. And it's easy for us to say that now, after I've spelled out why. You'd be surprised how many people don't know that this can be a problem.
Also, it amuses me that having a simple index into a Vec would be a "convoluted solution". It's the easiest solution of all the alternatives. It can also be risky for privacy.
Compare that to a GC'd language, where the easiest solution (just hold a reference) doesn't introduce privacy risks.
I wonder if this error could be preventable by Rust's type system so that you can't have indexes that fall out of sync with the underlying Vec. It definitely wouldn't be backward compatible, so it would have to a new type built on Vecs. Although like another reply to your comment points out, keeping indexes is unidiomatic (in many languages) and would probably cause other bugs, which would hopefully prompt a developer to rethink it, so maybe an abstraction on top of Vec isn't needed.
Doing it with an indexed Vec is basically re-inventing your own memory management system on top of the native one, which as you point out can get very contrived and error-prone. Because then you also have to re-invent allocation/freeing, removal of holes, etc etc.
People sometimes do this in VMs/interpreters where they really do need custom/"unsafe"[1] memory management, which makes sense, but it's definitely not needed for application code like this
[1] Of course it's still memory-safe, but it's more fallible in terms of panics and bugs, as you've pointed out
I would rather advise: don't reuse indices, even if that is the simplest solution that complies with the borrow checker. When one finds themselves reusing like that, that's when to turn to other more expensive approaches such as Rc.
> that's when to turn to other more expensive approaches such as Rc
If you're saying this was done just as an optimization... all I can say is, I hope you benchmarked first. As estebank pointed out, Rc is very fast: https://news.ycombinator.com/item?id=32240478. It can even be faster than mark-and-sweep in some situations. In fact the Swift language only uses reference-counting, not mark-and-sweep, at the language level.
If you profiled and found that the Vec approach solved some performance problem you had with reference-counting, then so be it. But I would be surprised if it meaningfully helped, and shocked if it helped enough to outweigh the extra complexity.
It is now also possible to specify “no debug info” for the release build in the build config.
It also affects obfuscation and licensing in commercial products. As you can map most functions to a file based off of this handling and find code to target. It's even worse, as if you were to strip the string and replace them all with giberish, it's still possible to map each file by xref's and find related functions. With how signature are in RE tools, you can automatically detect crypto functions and then map that every other function in the file, finding licensing checks easily.
The compiler should really respect privacy, and while the ticket is ongoing, it's been ongoing for 6 years and they just made it a bug last year, with no progress. This is a huge blocker for businesses or privacy related domains which instantly makes the language a no-touch.
Using CI/CD can still give forensic indicators as the paths are still in the binary, even if they arn't your host machine path. In authoritarian countries where people have to worry about security services, this is a big threat which can get people killed. It also leaks information, even if you don't view the information as valuable, it's still fingerprinting.
Pure paranoia. Find me one instance ever where anything like this has happened.
C:\Users\zhouh\.cargo\registry\src\github.com-1ecc6299db9ec823\aho-corasick-0.7.18\src\ahocorasick.rs C:\Users\zhouh\.cargo\registry\src\github.com-1ecc6299db9ec823\aho-corasick-0.7.18\src\classes.rs
I also know what version of the library he uses which means I can pwn anyone using this if a exploit comes out. And not only this library, I know the version for every library he's using. Like Chrono-0.4.19 from this string C:\Users\zhouh\.cargo\registry\src\github.com-1ecc6299db9ec823\chrono-0.4.19\src\sys\windows.rsSystemTimeToTzSpecificLocalTime failed with:
In strings there's actually 304 unique strings with his username in it. I know every file, I know every library. There's nothing stopping a malicious actor from downloading popular rust server binaries and using strings to determine if they have an exploit. And alot of software DOESN'T upgrade their libraries from vulnerable versions, especially if unmaintained. It's a big issue.
It's a real shame that Rust ignores this. And the fact that my original comment was so lambasted against really shows the amature nature of Rust users which don't align with real world organizational goals.
Skimming through the readme, I don't know what this gains over VNC and RDP solutions. Seems to be the same thing, but a different protocol?
this is like vnc but better. RDP is another beast altogether. i use rustdesk and RDP on a daily basis and they are for different things.
I feel like that's the main thing when talking about "TeamViewer alternative": not needing to setup external access / port forwarding on your router.
It's commercial software with free personal use.
i've stopped using teamviewer 3-5 years ago when they said i had violated home free edition. anydesk seemed to go that way last year or so and i jumped ship.
from my linux to windows 10 ltsc, alt-tab has issues, anydesk does not. anydesk has this fucking numlock bug for years now which hasnt been fixed. rustdesk does not have that.
i am able to watch youtube over rustdesk, anydesk chugs.
other than that, its just the same same.
i highly encourage people to move from anydesk (again, teamviewer is out a long time ago anyways) and rustdesk is a good alternative. good luck to the team.
edit: yes. file copy paste does not work from linux-windows, maybe it does windows-windows but i havent checked that while anydesk does this
The only bug / minor nitpick of Anydesk is that a Linux session host needs to explicitly initiate a new connection to the client for a file transfer, whereas on Windows hosts it happens transparently and just gives you a file picker alongside the existing session.
https://www.reddit.com/r/AnyDesk/comments/qiid2u/official_st...
last time i checked, they were mentioning something like 80 hours in 8 weeks or something that averaged to around 1.5 hours a day or something.... i did not bother waiting to get "whitelisted" because rustdesk works just as well without all this professional/free nonsense
You point the client to your server by including the address in the .exe filename on Windows. Be careful: encryption is not enabled by default.
Wait, what?
I'd proceed with caution. Apparently it doesn't support Wayland, so when you run it under Wayland it offers you a "Fix it!" button that, when clicked, runs sed on some gdm system config files to revert it to X11 (nevermind that gdm is far from the only way to use Wayland): https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform.... If this is the kind of thing that's considered acceptable by the developer, I'd rather keep their products far away from my machines. A quick glance at the code also reveals an almost complete lack of comments and copious use of unexplained `unsafe`.
Reminds me of the early 2000's - phpBB, etc.
Python had a similar phase.
There's a class of programmers / power users out there who are looking for products with less probability of memory security problems bundled in (as is the case by default with most C programs, sadly) -- and I am one of them.
I can't say I care about including the "Rust" word in the name of the product itself -- that's indeed a bit silly -- but I do insist on using Rust-written programs because as far as I am aware, the few servers I manage and monitor never once had a Rust program crash unexpectedly. These servers are ~19 months old at this point.
And as a guy periodically working with Rust as well, I am aware of its promises and guarantees and I have personally ascertained they are not imaginary and they do indeed work well. And I'll keep seeking out and using Rust-written software going forward as well.
(EDIT: It's fine to disagree but I can't argue with anonymous silent disagreements. Could you voice what you dislike about this comment, please?)
I still see broadly that most users don't care, nor should they. Quality speaks for itself. If Rust helps with that, that's fine, but in the long run it's overly techy branding. Of course this is an open source thing, so really geared to nerds, so there's that.
I didn't finish my thought, sorry about that: I meant that it's up to us the techies to push what's of objectively better quality into the spotlight for the non-tech users to adopt. And I do that when the opportunity arises.
That said, I still think "RustDesk" comes off kind of cheesy here. I think mostly because it's not a one-off utility where using Rust would be a primary factor, but it's high level enough that highlighting the implementation language so prominently comes off a little funny. Like you couldn't differentiate the product enough on its own so you had to highlight the language you used?
I will have a look at it, but in this example that's a very mild initial turnoff for me. I must be spoiled to be so picky!
Edit: after poking around a bit more, this looks pretty interesting. The intro "Yet another remote desktop software" would indicate that there's a lot of options out there, and they are trying to differentiate themselves. Maybe highlighting Rust in this case _is_ actually an important signifier of a stronger dedication to writing a lean application (I'll find out soon!). I'll retract some of my knee-jerk uninformed hesitance above.
And its not unique to include the language name. Say, for which program is .el? And that extension is commonly included in projects. Not a jab at Emacs as its same with vim projects but they start with vim instead.
(I actually find it useful as its descriptive.)
In fact, my perception from just the naming is that it’s some sort of academic or personal project built in Rust (because the author probably was interested in dabbling with the language).
And with a personal project, I associate “this is something not ready for production”, even though it very well could be.
If the selling points were a smaller memory footprint or a more stable app, a name like TinyRemoteDesktop or StableRemoteDesktop seem more indicative of its advantages.
That's not what TeamViewer, AnyDesk and others offer. They offer display and control of anyone's PC, without a tech-savvy person on that end. There's no way any open-source project could compete in this space.
To compete in this space is its main purpose and I'd say it does a pretty good job.
Besides good UX, you need at least a Microsoft signed driver for efficient capture. You need extensive testing on a wide (and wild) variety of legacy hardware and OSes.
Maybe RustDesk does a good job, I didn't try it, but it's absolutely not an alternative to TeamViewer.
That's needlessly negative. They offer their own relay server or the possibility to host your own. From the documentation it seems like they're aiming for the same UX as TeamViewer, for which we desperately need an OSS alternative that's equally user-friendly. Saying that it's an unreachable goal is defeatist and pure speculation.