RustDesk – Remote desktop software, written in Rust(github.com)
github.com
RustDesk – Remote desktop software, written in Rust
https://github.com/rustdesk
21 comments
I guess it's a testament to how loved Rust is as a language that there are so many projects posted here with "...built in Rust".."written in Rust". I like Rust, but in some contexts I wonder how or why it matters that it was written in Rust (I know there are some projects where for security or other reasons it may actually matter) to me as an end user or at least why it's so important that posts introducing the project lead with that fact. Sometimes, it just seems like a low level implementation detail that is unimportant. Naming the entire project after Rust ("rustdesk") is a whole new level though :)
It's an actual selling point more than a "loved" situation.
If I see something built for massive concurrency and I see Erlang or Elixir, I'm immediately much more confident in the tooling.
If I see something written in Rust, I'm confident in it's memory safety at a minimum but it usually bodes well for quality code in general.
If I see something built for massive concurrency and I see Erlang or Elixir, I'm immediately much more confident in the tooling.
If I see something written in Rust, I'm confident in it's memory safety at a minimum but it usually bodes well for quality code in general.
> bodes well for quality code in general
Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly.
As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker.
Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.
Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly.
As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker.
Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.
It depends.
- Rust is a complicated language, so novice developers probably use something else.
- Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers).
- You get memory safety in safe Rust code and don't need a garbage collector.
- Non-optimal solutions usually are visible/more cumbersome to write.
In the end it's up to the individual developer, but Rust really helps to produce high-quality code.
- Rust is a complicated language, so novice developers probably use something else.
- Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers).
- You get memory safety in safe Rust code and don't need a garbage collector.
- Non-optimal solutions usually are visible/more cumbersome to write.
In the end it's up to the individual developer, but Rust really helps to produce high-quality code.
> Non-optimal solutions usually are visible/more cumbersome to write
How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.
How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.
A few examples:
- Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible.
- Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible.
- Rust requires you to use Box for heap allocations, it's visible.
Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".
- Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible.
- Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible.
- Rust requires you to use Box for heap allocations, it's visible.
Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".
Yeah I think that's just called enforcing best practices, not optimal solutions.
One cannot enforce optimal solutions but one can prevent sub-optimal ones through proper checks.
You keep using that word, I don't think it means what you think it means.
And the community and philosophy/culture the languages come with seems to promote that as well.
Language choice is absolutely a powerful indicator of expected code quality. I don't want to start a language flame war, but I have some heuristics around P(I am satisfied with software|software is written in language X) that are very predictive.
Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.
Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.
It's a bit of a curse though, isn't it? If a language becomes popular enough rather than something used only by enthusiasts, then all sorts of crap will appear?
Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).
Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).
I think this especially true when someone is explicitly remaking something in Rust to make it more performant
"X but in Rust" IME almost always implies something with at best feature parity, but also debloated code
"X but in Rust" IME almost always implies something with at best feature parity, but also debloated code
That's fair. Code quality may have been a stretch.
I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.
I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.
Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.
To push this argument further along, in numerous use cases the GC using languages have comparable memory safety and performance (thus equal mention by government agencies), but were easier to use or faster for production.
No language will save you from:
- A lack of knowledge about the domain, this includes the technical framework in which your program exists, behaves and interacts
- Code errors which result in valid code, but does the wrong thing, Rust isn't magic
- Bad choice of datastructures and algorithms
- Incomprihensible code documentation and bad development practices.
While I get that languages can eliminate a type of problem, they don't eliminate badly written software. Most of the time, the software development process itself, is more important, if you really want to examine what it means to build secure/safe software.
Having a team dedicated to developing software safely and using a language with stronger type safety guarantees vs. having a person just build something with the same language, does not magically imbue the end product with good qualities.
Take your example, if you don't have a good foundation in distributed systems, and try to build a distributed system in Erlang, you will only get so far, before you hit your head against the wall so hard, you start studying distributed systems instead.
While I get that languages can eliminate a type of problem, they don't eliminate badly written software. Most of the time, the software development process itself, is more important, if you really want to examine what it means to build secure/safe software.
Having a team dedicated to developing software safely and using a language with stronger type safety guarantees vs. having a person just build something with the same language, does not magically imbue the end product with good qualities.
Take your example, if you don't have a good foundation in distributed systems, and try to build a distributed system in Erlang, you will only get so far, before you hit your head against the wall so hard, you start studying distributed systems instead.
This kind of thinking is strange. It's similar to saying no type of exercise can save you from death. While true, we are talking about probability bounds here, not certainties.
I totally understand what you are saying, in terms of probabilities, but what I'm arguing against, is thinking that safety, robustness etc. for a program is just a given, just because you happen to use Rust or whatever else is claiming X feature. In it's essence, it's like saying something is made of military grade materials, but then the materials are used all wrong in the actual design or not of importance at all. The fact that someone used Rust, does not really tell me much, other than certain types of errors are eliminated, and that is assuming they used Rust correctly, for the type system to work properly.
If you ask people explicitly about whether Rust just makes better products, they might say that they have doubts, or give a vague answer. But asking like this is just a leading question, and therefore the process itself of asking the question, will probably cast doubt over some automatic assumptions about what the type safetly of Rust really does for the end product.
But the reality is, "Made with Rust" is starting to look like a certificate/claim of validity, and its definitely not, just like any other language isn't either.
If you ask people explicitly about whether Rust just makes better products, they might say that they have doubts, or give a vague answer. But asking like this is just a leading question, and therefore the process itself of asking the question, will probably cast doubt over some automatic assumptions about what the type safetly of Rust really does for the end product.
But the reality is, "Made with Rust" is starting to look like a certificate/claim of validity, and its definitely not, just like any other language isn't either.
It's one of dozens if not hundreds of memory-safe languages. The false marketing claim that Rust somehow invented it is absolutely infuriating.
For one reason or another, those other languages didn't take off and Rust did.
Language adoption isn't just about technical merits (although those have to be there). The ecosystem, tooling, core team, learning resources, and overall community have to be there, too.
To your point - if I want to get started in another language that is 1) statically compiled, 2) non-garbage collected, and 3) memory-safe by design, as far as I can tell my only other mainstream options are Swift / Objective-C, Ada / SPARK, and Nim. I don't see nearly as much activity in those language's open source ecosystems, and "basic" libraries might not even exist due to the small communities.
Language adoption isn't just about technical merits (although those have to be there). The ecosystem, tooling, core team, learning resources, and overall community have to be there, too.
To your point - if I want to get started in another language that is 1) statically compiled, 2) non-garbage collected, and 3) memory-safe by design, as far as I can tell my only other mainstream options are Swift / Objective-C, Ada / SPARK, and Nim. I don't see nearly as much activity in those language's open source ecosystems, and "basic" libraries might not even exist due to the small communities.
Nim is garbage-collected, actually. It has an option to disable garbage-collection (though I thought there was talk of removing that at some point) but then it just leaks memory, it doesn't have a comprehensive system for GC-less memory management like Rust does.
Nim is also not the only language with the combination of optional GC and memory management. Dlang and Vlang are two others, where the GC is optional and are compiled languages. Golang appears to be more seriously experimenting with various forms of manual memory management, so at some point, we might see it offer a choice of memory management options too. In fact, Dlang even has an experimental borrow checker.
Care should be taken to not be in so much of a bubble, to not realize that other languages have viable solutions too or are developing alternatives to what's presently available. If our choice for one or the other, is more a matter of personal preference, it would arguably be better to acknowledge such.
Care should be taken to not be in so much of a bubble, to not realize that other languages have viable solutions too or are developing alternatives to what's presently available. If our choice for one or the other, is more a matter of personal preference, it would arguably be better to acknowledge such.
Friend nim does have gc less memory management https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... and can also collect cycles similar to PHP. Imo the new system is more intuitive than rust's which will be a huge win when it comes out (soon).
> The false marketing claim that Rust somehow invented it is absolutely infuriating.
This is the second time I've seen someone say this in the last week or so, but I've never seen this claim in the wild, and certainly not by Rust's core team or organization. It's also not a secret that Rust's memory management is heavily influenced by Cyclone. Can you show an example of someone making this claim?
This is the second time I've seen someone say this in the last week or so, but I've never seen this claim in the wild, and certainly not by Rust's core team or organization. It's also not a secret that Rust's memory management is heavily influenced by Cyclone. Can you show an example of someone making this claim?
[deleted]
Remote desktop software is traditionally the source of many hacks - like exploiting the software itself, not just using it. So there is a relevant security angle here.
Aside from that though - there's a lot of comments on rust threads in general about how Rust isn't ready for this or that or the next thing, so these types of projects showcase that maybe the "not ready" info is outdated or over-exaggerated.
It's also one of those things that seems to occur "naturally" as a language becomes more widely adopted. A few years ago there were tons of projects linked here about "x - a tool for y written in go". And before that ruby or python, etc.
Aside from that though - there's a lot of comments on rust threads in general about how Rust isn't ready for this or that or the next thing, so these types of projects showcase that maybe the "not ready" info is outdated or over-exaggerated.
It's also one of those things that seems to occur "naturally" as a language becomes more widely adopted. A few years ago there were tons of projects linked here about "x - a tool for y written in go". And before that ruby or python, etc.
This comment is so common here I decided to do a quick search here on HN:
- written in go: 1331 results
- written in rust: 1043 results
- written in python: 763 results
- written in javascript: 525 results
Not intended to be scientific and there are false positives but you get my point. Personally I appreciate not having to visit the repository to find out. A tool being written in a language I know and enjoy is a benefit.
- written in go: 1331 results
- written in rust: 1043 results
- written in python: 763 results
- written in javascript: 525 results
Not intended to be scientific and there are false positives but you get my point. Personally I appreciate not having to visit the repository to find out. A tool being written in a language I know and enjoy is a benefit.
> A tool being written in a language I know and enjoy is a benefit.
Sincere question: why? I 100% agree about libraries, but why does the implementation language of an application matter to you?
Sincere question: why? I 100% agree about libraries, but why does the implementation language of an application matter to you?
I enjoy tinkering and making my life unnecessarily difficult is a hobby. To give you an example i use:
- dwm as window manager
- neomutt for email
- newsboat for feeds
- notifications with inotifywait/watch and notify-send
- vim keybindings EVERYWHERE
Because of this the I've become very reliant on the ability to tweak and customize the tools I use. I know I'm a minority but I'm so deep down the rabbit hole I can never go back.
- dwm as window manager
- neomutt for email
- newsboat for feeds
- notifications with inotifywait/watch and notify-send
- vim keybindings EVERYWHERE
Because of this the I've become very reliant on the ability to tweak and customize the tools I use. I know I'm a minority but I'm so deep down the rabbit hole I can never go back.
On neomutt, use a Maildir config and use isync (mbsync) and msmtp. It's godly fast. No IMAP(S) related hangs, no needs to be online 24h, no slowdown over GUI's. Write your mails and queue them, send them later.
I am, and the sync is a cronjob triggering inotifywait watching the directories I'm interested in. Only thing I wish I had is less hassle unlocking the password file but I'll get there.
Well, if the source is available you can do what you want with it.
I don't know a thing about Ruby and for awhile really felt out of it when stuff was being written in it a lot more.
I don't know a thing about Ruby and for awhile really felt out of it when stuff was being written in it a lot more.
Yup, a lot of false positives without quotes. Searching with quotes on Story gives the following. (Search is case insensitive.)
"written|built in Rust" 832 (790|42)
"written|built in Go" 809 (792|17)
"written|built in Python": 390 (364|26)
"written|built in Javascript/JS" 269 (220|14) / (32|3)
"written|built in Java" 107 (101|6)
"written|built in TypeScript" 66 (61|5)
"written|built in C#" 41 (38|3)
"written|built in Stone" 10 (10|0)
Replying to my own post for posterity because edits are closed and I missed the obvious Go/Golang. This pushes Go to the top winning it a "major award".
"written|built in Go/Golang" 918 (792|17) / (102|7)
"written|built in Rust" 832 (790|42)
"written|built in Python": 390 (364|26)
"written|built in Javascript/JS" 269 (220|14) / (32|3)
"written|built in Java" 107 (101|6)
"written|built in TypeScript" 66 (61|5)
"written|built in C#" 41 (38|3)
"written|built in Stone" 10 (10|0)
To be fair to Rust, Go evangelists can be just as annoying. I say this as a Go evangelist :)
According to the comment you replied to, you're statistically more annoying.
I assumed the "annoying" part comes from telling other people to rewrite stuff in ${LANG}. While a number of projects "writte in ${LANG}" could correlate with the annoyingness as defined above, in my experience Go evangelists are more aware that their language is not end-all be-all, but is actually useful in a certain niche of IO-heavy applications, so evangelism is much less pronounced.
[deleted]
> Naming the entire project after Rust ("rustdesk") is a whole new level though :)
That happens to most ecosystems that go through a "hype cycle" just like Rust is right now. So many Go projects have something "Go" in them, same with JavaScript, Ruby and all the others who've walked the path.
That happens to most ecosystems that go through a "hype cycle" just like Rust is right now. So many Go projects have something "Go" in them, same with JavaScript, Ruby and all the others who've walked the path.
Hah right. I'm surprised at how protracted this hype cycle is.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Back in 2011 or so, until forever, it felt like every day there was a mandatory "X made in Ruby" frontpage story as well. I'm sure this one will pass too, once a new language appears that everyone HAS to write everything in.
Yeah, I really think it's weird to include the language name in the package name unless it's a language-specific library (with no FFI... C libraries almost never include C in their names) or bindings to something. The language is (usually) an implementation detail for an "app"
And in this specific case, a rusty desk is probably not what most people want, so if you want any non-programmers to use it... it's not the best name.
And in this specific case, a rusty desk is probably not what most people want, so if you want any non-programmers to use it... it's not the best name.
Normally I see the name of the language included in libraries, not applications. In that context it makes a bit more sense because it actually does matter what language the library was written in/for. For a remote desktop application it's hard to see why it's relevant enough to be included in the name.
It's not that it's impossible to write secure code in C/C++ or that it's impossible to write insecure code in Rust, but Rust makes it much harder to write a particularly prevalent class of bug (memory safety).
These bugs are obviously particularly bad because of the security implications, but even for applications where you don't care about security having the app randomly segfault is no fun. All else being equal, I would choose an application written in Rust over C/C++.
That said, obviously the name of this project is just because the author likes Rust a lot. It happens in other languages too ("go" in Go projects, "py" in Python projects, etc).
These bugs are obviously particularly bad because of the security implications, but even for applications where you don't care about security having the app randomly segfault is no fun. All else being equal, I would choose an application written in Rust over C/C++.
That said, obviously the name of this project is just because the author likes Rust a lot. It happens in other languages too ("go" in Go projects, "py" in Python projects, etc).
Is this the new “I’m on Arch btw”? The comment you’re replying to doesn’t say anything about memory safety or C++
No it's the new "I use go btw" (which itself is the new "just use python for that", which was the new "do it in java for portability". I wasn't old enough to witness C++'s initial rise, but it was famous for it's hype squad and people selling it as a silver bullet. As was C (that slow language will never be as good as a real programmer doing it all in assembly is the story there IIRC)).
Rust's security improvements the comment I'm replying to mentions come from the fact it is memory safe. C/C++ are just the obvious comparison for a very popular memory unsafe language.
It's a reliable way to get engagement on HN. You're guaranteed lots of comments from the Rust Evangelism Task Force as well as people inevitably asking why everyone mentions their projects are written in Rust.
It's worth noting that for a few years people suffixed all their stuff with "made in node" to get upvoted and then for a while with "made in go". I always tell my clients not to fall into the trap of treating personal preferences as the optimal solution to a problem.
I have no problem with noting that it is written in Rust. But why name the app after the language?
Rust apps are in their "Nintendo 64" era
Maybe that's the most interesting or distinguishing feature of the app?
What I find most interesting is that it has better UI than AnyDesk. I haven't used TeamViewer in so long, I can't comment on it.
I haven't used either AnyDesk or TeamViewer. Looking at the snapshot in the linked article, RustDesk looks like a web page. The window chrome looks like macOS, but the application does not look very Macintosh-y. I personally don't think it looks great, but if it works well enough, maybe that doesn't matter.
My biggest complaint about AnyDesk is that sometimes I have to walk people through downloading and installing it over the phone. When AnyDesk is installed, the tab with the connection ID is overlaid by a tab with an ad. At that point I have to give up because many people don't understand tabs and don't know how to close it or switch tabs so they can see the connection ID. Very user unfriendly. I was very glad to see RustDesk come along.
Like others have already mentioned, _usually_ programs written in Rust are far more stable than their respective C/C++ implementation.
One impressive data point (for me) is this: https://youtu.be/GtRo-eF8-TE?t=671
One impressive data point (for me) is this: https://youtu.be/GtRo-eF8-TE?t=671
It starts off as a way of inviting other rust programmers to contribute. But then the project matures and becomes an end user product and we end up like this project. The fact that we see so many rust* project is a testament to the usability and power of the language.
A couple of years ago there was an avalanche of posts about projects written in Go. Today's hyped language is Rust. Give it another couple of years and some new language will have taken its place here.
My thought process is that Rust's memory model not only has a positive impact on security, but on program correctness all up. This means fewer lock ups, better performance, resource utilization etc. without so much effort from the developer. As such, while the 'built with Rust' label is no guarantee of a well-written program, it certainly avoids certain pitfalls that other languages are more susceptible to with a minimal performance tradeoff.
in my case being built in rust is a benefit. elixir is my daily driver and rust fills a niche for me (all the domains where elixir isn't great) and they pair well together thanks to rustler.
A project being written in rust communicates to me that if I ever wanted to join the community and start submitting patches, I could. I have little interest in devoting the next 10-15 years "mastering" c++ but I'm happy to dig into rust.
A project being written in rust communicates to me that if I ever wanted to join the community and start submitting patches, I could. I have little interest in devoting the next 10-15 years "mastering" c++ but I'm happy to dig into rust.
The Rust community seems to be obsessed with the idea of re-writing every prior piece of software in Rust, to such an extent that there is a specific word for it: RIIR. This is sometimes funny, since it demonstrates the incentive to be "approved", to be praised, for some reason unknown to me. And yet, I don't see much game-changing software written in Rust, such as Docker or Kubernetes.
Rust projects are infinitely easier to contribute to.
Agree the underlying language is not to important.
On the other hand when I see built with Rust I have high confidence it’s going to be fast, bloat free, easy to install binary and not some slow website packaged in electron made to look/feel like an app or some NodeJs app with 1000s of random dependencies.
On the other hand when I see built with Rust I have high confidence it’s going to be fast, bloat free, easy to install binary and not some slow website packaged in electron made to look/feel like an app or some NodeJs app with 1000s of random dependencies.
> or why it matters that it was written in Rust
Because it's an accomplishment to ship anything of complexity in Rust! /s
Maybe you can look at it as "wow, it's an entire application with no unsafe code and really good (perfect?) memory safety"?
Because it's an accomplishment to ship anything of complexity in Rust! /s
Maybe you can look at it as "wow, it's an entire application with no unsafe code and really good (perfect?) memory safety"?
As an exercise, think what the result would be if it was "written in PHP" instead.
This gets posted again and again, and every time I look at it, the code quality is absolutely terrible. Remote access software is by design a complete internet-accessible backdoor to your system, I will never use one that is written as shoddily as this one.
Also note their persistent refusal to implement TLS for their web access.
This attitude alone tells me never to trust this project ever, even when they finally should use TLS.
Sadly there is no other FOSS out there that combines remote support with good NAT traversal. Existing remote access tools such e.g. VNC all do not offer NAT traversal and are incredibly hard to setup. All FOSS web/phone conference tools offering screen sharing refuse to implement transferring Cursor/Keyboard control. Probably because it is not so easy, but mostly, I guess, out if fear for diffuse security problems.
Too bad people then will be compelled to use this absolute mess...
Sadly there is no other FOSS out there that combines remote support with good NAT traversal. Existing remote access tools such e.g. VNC all do not offer NAT traversal and are incredibly hard to setup. All FOSS web/phone conference tools offering screen sharing refuse to implement transferring Cursor/Keyboard control. Probably because it is not so easy, but mostly, I guess, out if fear for diffuse security problems.
Too bad people then will be compelled to use this absolute mess...
I work on the Desktop Access feature for Teleport: https://goteleport.com/docs/desktop-access/getting-started/
The tool itself is open core: https://github.com/gravitational/teleport
Most of the desktop access stuff is open source. (The only desktop related thing that's proprietary is our tool that allows for access to machines not connected to Active Directory). A sizeable chunk of the desktop access code is even Written In Rust™: https://github.com/gravitational/teleport/tree/master/lib/sr...!
The tool itself is open core: https://github.com/gravitational/teleport
Most of the desktop access stuff is open source. (The only desktop related thing that's proprietary is our tool that allows for access to machines not connected to Active Directory). A sizeable chunk of the desktop access code is even Written In Rust™: https://github.com/gravitational/teleport/tree/master/lib/sr...!
Are you talking about their website, rustdesk.com? It looks like they have HTTPS version of "rustdesk.com" but don't redirect to it automatically.
Do you have any links to issues/interactions you find concerning? I've been evaluating different remote desktop tools recently and I'd certainly like to know about any other red flags.
Do you have any links to issues/interactions you find concerning? I've been evaluating different remote desktop tools recently and I'd certainly like to know about any other red flags.
I think I found the issue: https://github.com/rustdesk/rustdesk/issues/856
Furthermore they seem to share servers with what seems like an unrelated ecommerce website: https://github.com/rustdesk/rustdesk/issues/2712
It doesn't seem like they take security all that seriously.
Furthermore they seem to share servers with what seems like an unrelated ecommerce website: https://github.com/rustdesk/rustdesk/issues/2712
It doesn't seem like they take security all that seriously.
It's written in Rust, it can't be terrible! /s
Are there any other remote desktop services what work out of the box to access servers behind firewalls and has clients for mobile and all desktop devices?
not to criticize your answer, i just have not found any viable alternative that is free to use for all use cases.
not to criticize your answer, i just have not found any viable alternative that is free to use for all use cases.
whats the commercial options code quality looking like?
Ssh x11 forwarding is at least supremely battle tested over decades.
Yup and unfortunately a feature that Wayland decided wasn't worth preserving.
Waypipe exists.
Maybe not much better, but that's hardly the only alternative
Could you share what you use?
Lots of chatter that it has some issues
https://youtu.be/JIAdEGX_sIU
Makes changes to system
https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform...
I prefer meshcentral myself
https://youtu.be/JIAdEGX_sIU
Makes changes to system
https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform...
I prefer meshcentral myself
It no longer changes system configuration on the master branch
https://github.com/rustdesk/rustdesk/pull/3002
https://github.com/rustdesk/rustdesk/pull/3002
Ill never trust them not to pull shit like that again.
Plenty of reddit threads to on issues with relay servers (china) etc. Boils down to i just dont trust it anymore
Plenty of reddit threads to on issues with relay servers (china) etc. Boils down to i just dont trust it anymore
This is particularly interesting, the commit modified the `WaylandEnable` option in the file "/etc/gdm3/custom.conf" to "false", disabling Wayland and enabling X11.
But even more interestingly so, the modification is performed with elevated privileges, via `pkexec` command.
Yikes.
But even more interestingly so, the modification is performed with elevated privileges, via `pkexec` command.
Yikes.
Exactly. Unforgivable in my book
Last time I checked, this application did a dirty thing to my /etc to force X sessions instead of Wayland. You can do these things, but please be upfront and ask me first - I certainly do before depositing bodily fluids in places I do not own.
You may be glad to hear that it doesn't do those things anymore, and native wayland support has started to be integrated: https://github.com/rustdesk/rustdesk/pull/3002
Obvious question that I couldn't find any answer to: How does the latency compare to existing solutions?
I currently use RealVNC and Steam's own VNC thing to connect to a desktop computer in the same city as where I'm connecting from. RealVNC is much laggier than Steam, which seems optimized for latency. The ping latency is something around 10-15ms (at peak hours, otherwise less), but somehow RealVNC manage to still be kind of laggy, at least compared to whatever Steam is doing.
The use case is doing game development (in Unreal Engine) via a shitty laptop, connected to a proper desktop computer.
So how would RustDesk compare to RealVNC/Steam here?
I currently use RealVNC and Steam's own VNC thing to connect to a desktop computer in the same city as where I'm connecting from. RealVNC is much laggier than Steam, which seems optimized for latency. The ping latency is something around 10-15ms (at peak hours, otherwise less), but somehow RealVNC manage to still be kind of laggy, at least compared to whatever Steam is doing.
The use case is doing game development (in Unreal Engine) via a shitty laptop, connected to a proper desktop computer.
So how would RustDesk compare to RealVNC/Steam here?
When i play games on windows from my mac i used steam, rustDesk was a bit slower last time i checked (approx 1 year ago). However rustdesk is more flexible when it comes to remote access or number of plattforms the client is available (in my case iOS).
I've heard good things about Parsec if you're connecting to a non-Linux machine.
I can second that. Parsec is the best remote-access software I've used, bar none. The lack of Linux hosting is an unfortunate downside.
Thank you for this recommendation. I'm connecting to a Windows machine from Windows/Linux/macOS and Parsec works really well, low latency and good quality. Much better than RealVNC and access to the full desktop compared to Steam.
Big thanks to you!
Big thanks to you!
The "written in Rust" part is just because it is so impossible hard to do anything in Rust that its developers have to brag about it.
Looks interesting! I'm currently, and thankfully, not responsible for any infrastructure where this would be useful, but will definitely check it out the next time the need arises.
TeamViewer is (both technically and commercially) awful, and getting rid of it is always priority #1 when taking on a new environment. You always run into fun stuff like 'oh, yeah, this 4-years obsolete version is running on our main accounting server all the time, as that's the only thing the vendor supports, and they need to be able to get in at all times'... 'yes, indeed, using only a 4-digit PIN, why do you ask?'...
Being able to supply your own RustDesk rendezvous/relay server is especially interesting to me, as features like proper SSO-linked 2FA, a log of who accessed what from where (hopefully including file transfers), and alerts on large data flows becom a lot easier to implement that way.
TeamViewer is (both technically and commercially) awful, and getting rid of it is always priority #1 when taking on a new environment. You always run into fun stuff like 'oh, yeah, this 4-years obsolete version is running on our main accounting server all the time, as that's the only thing the vendor supports, and they need to be able to get in at all times'... 'yes, indeed, using only a 4-digit PIN, why do you ask?'...
Being able to supply your own RustDesk rendezvous/relay server is especially interesting to me, as features like proper SSO-linked 2FA, a log of who accessed what from where (hopefully including file transfers), and alerts on large data flows becom a lot easier to implement that way.
Sadly TeamViewer is the only thing that works on old Android Point-of-Sale devices which are still numerous. And since Android requires the manufacturer signature to do screen sharing on older versions and those manufacturers are either dead or too big to care, it will remain to be so.
I can't wait though for the day the place I work for decides to drop support for them and stops paying for that... thing as it's not only extremely expensive and awful from a security perspective but also from a general quality one: some days their server just decides to not log you in, they have a nasty crashing bug that often happens when you resize your meeting window that has been there literally for years, among other things.
I can't wait though for the day the place I work for decides to drop support for them and stops paying for that... thing as it's not only extremely expensive and awful from a security perspective but also from a general quality one: some days their server just decides to not log you in, they have a nasty crashing bug that often happens when you resize your meeting window that has been there literally for years, among other things.
Someone recently mentioned they have "AI fatigue". Is Rust fatigue a thing?
A piece of metal with rust could be called fatigued.
It was extremely laggy and nearly impossible to connect so I installed the docker on a server and got exactly the same result.
No idea if I did something worng, but it's unusable for me in the current state.
Anyhow, I'm still very intrested in a working version of this.
Did you guys had better luck than me?
No idea if I did something worng, but it's unusable for me in the current state.
Anyhow, I'm still very intrested in a working version of this.
Did you guys had better luck than me?
It seems to be getting a lot of hate here (where I found it) but I've been using it for over a year now. One of my developers used to drop into my mac from windows to do builds and diagnose ios issues plus spend non trivial time setting up other things, it was basically on for hours. Latency was good, no issues whatsoever in our time using it.
I use this to remote into my Mac Mini from my Windows machines and it is very good. VNC is awful on Macs for some reason, unless you're using it from another Mac.
I installed it on my laptop (Linux Mint) and mobile. It works. But how does one shut it down? Closing the UI doesn't kill the service.
Tried it, deployed open rendezvous server, but it was really slow (and back then didn't support ivp6).
I'm using dwservice now, but still on a lookout for a self hosted solution.
I'm using dwservice now, but still on a lookout for a self hosted solution.
I found this program last week and replaced AnyDesk with it, but after reading all the comments around the security issues and especially seeing that their relay servers are potentially hosted in Beijing, I'm feeling a bit sick to my stomach honestly. I'm going to uninstall it and do more research. I'm not comfortable with the ambiguity around something that is effectively an open door to my entire system.
> I'm not comfortable with the ambiguity around something that is effectively an open door to my entire system.
But the back door is written in Rust, so it's a secure, well-built backdoor, a backdoor you can trust.
But the back door is written in Rust, so it's a secure, well-built backdoor, a backdoor you can trust.
> replaced AnyDesk
What were your dislikes with it? Thanks.
What were your dislikes with it? Thanks.
Well it's technically not free - although you can still use it for free after the trial period, but they can disconnect you at any time - and I would lose connectivity sometimes. The main reason for switching to RustDesk is so I can build my own version and deploy it on the work laptop. I'm using PiKVM to VNC into the work laptop right now, but it's a poor alternative at the moment with the latency and resolution issues in TigerVNC.
I absolutely love the idea of this, but the Google-like gui and controls bring it down so much
Has the Headless Remote issue been resolved with it?
I remember it was not able to remote into headless servers when last I used it!
Can imagine this will be really useful for the helpdesk scammers that get more and more banned by similar commercial providers
Wondering if there will ever be a arch64 (m1/m2) version of rustdesk for the mac. It is currently intel only
I tried this about a month ago, but it caused my android tablet to hard reboot when trying to connect to my PC.
Unable to get encryption working with self-hosted docker versions.
wow. i am in love with rustdesk.
this is the most active and impressive collaborative community of developers who are VERY VERY responsive to all questions and are helpful in improving the software.
this is the most active and impressive collaborative community of developers who are VERY VERY responsive to all questions and are helpful in improving the software.
between the comments pointing out numerous serious security issues and those who point out poor code quality or phoning home to china, the comment i am replying to feels strongly like astroturfing
phoning home to china? what's that?
how many of those posters have created issues on github regarding these things?
phoning home?
security issues?
poor code quality?
edit: would you be comfortable with google analytics in exchange of "phoning home to china"?
how many of those posters have created issues on github regarding these things?
phoning home?
security issues?
poor code quality?
edit: would you be comfortable with google analytics in exchange of "phoning home to china"?
Google analytics is not a requirement for remote desktop software either. That said, to answer yor question, I would absolutely prefer Google analytics over phoning home to China.
Can I use this to control a Chromebook?