I *REALLY* want to love this, but it just honestly all-around doesn't work very well or reliably. The developer is almost impossible to communicate with. They don't have CI setup very well at all. It's also nearly impossible to selfhost. I'll be forced to keep using Anydesk until there's something that can at least match it in stability and features. There is potential for this to be good, but not without a LOT more change. Source for my experience is that I co-maintain this package: https://aur.archlinux.org/packages/rustdesk
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?
Not 100% open source, but a good solution for controlling my parent's laptop when they need a hand with something (they live in England, I live in Scotland) is to use ZeroTier to set up a VPN (installed it on their laptop when I had physical access to it, uses basically no system resources and just runs in the background automatically) and then use RDP built into Windows (I installed Windows 10 Enterprise on their laptop when I first set it up, have loads of MSDN keys from work).
Another alternative is to install an SSH client and setup an automatic connection with your server (using a password-less key). Just forward RDP and don't let the user open a shell. I think that's possible via ForceCommand in the sshd config [1]. So if the client machine is hacked, your server will not be compromised.
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.
Not sure about Bitvise SSH server, thanks for the recommendation though, is that Zerotier works behind firewalls. Don't need to do any port forwarding etc. Very similar to Logmein's Hamachi.
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.
Zerotier is my goto tool too(I use tightvnc server even on Windows instead of RDP)!
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.
Isn't everything Wayland related an everlasting work in progress? Especially thanks to Nvidia not playing ball.
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.
Amusingly it is thanks to Wayland i can use Linux on my GPD Win 1 handheld[0] - apparently there is a bug in the video driver that when changing video modes can cause the entire screen to shift several lines (probably some memory offset issue, sometimes it even causes colors to go haywire) that needs a reboot to fix.
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)
> Of course that means that games that do not support 1280x720 wont work at all,
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.
IDK, I've been on Wayland (via Sway) for about 5 years now, there were a few annoyances in the first few years but now I can't remember when was the last Wayland related thing that I needed to fix.
Screen sharing is a bit challenging but possible.
It is not too long when it was impossible.
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.
So, you didn't notice that video playback in Firefox isn't hardware accelerated and stutters a lot? (Firefox' sandbox prevents itself from creating the OpenGL context needed for hardware accelerated video playback).
This entire subthread is exactly why I don't believe people when they trout out old linux desktop stereotypes and then handwave and imply they've actually tried it anytime recently. Shocking, in development efforts can undergo lots of change in the span of months, let alone years.
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.
I've had it on a few generations of nuc's and an XPS 9590 (where I disabled the nvidia card). I use it for DevOps mostly. So no gaming, don't have time for that anyway.
Sheesh, yeah. Wayland is one of those aspirational things I check in with every once in a while, like Star Citizen or fusion power or the moral arc of the universe bending toward justice. They're nice things to think about, in dark moments, but I don't think one should bet on their successful implementation.
Do you actually checkin on it or do you just go off the armchair comments from other folks that clearly haven't tried it anytime recently? Hardware acceleration (webgpu, vaapi, etc in Firefox), support for embedded platforms, mixed mode DPI, 360Hz screen support, fractional (albeit suboptimal for now but perfectly fine) scaling (miss me with complaints about proprietary electron clients), vulkan support, and soon there will be considerably better scrolling support than in x11, maybe even full top-bottom support for fractional scaling the list just goes on and on.
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.
It doesn't seem so bad right now if you use Sway/GNOME/KDE. I have Wayland enabled on my Intel+NVIDIA laptop and it's been pretty much fine after installing the proprietary drivers.
This was on fedora 36... mostly screen will not wake from sleep, but also black lines on the screen, and complete signal mess up where I can barely see what's happening. I tried everything, like switched from hdmi to display port cables, installed latest drivers from nvidia, still it's a mess. Wasted countless hours jerking around with it. It was so unusable and gave up even trying any more a couple months ago. Maybe will try in a few more months because I would really like to use the machine with an external monitor.
I have learned my lesson, and will NEVER buy another nvidia product, not worth the trouble.
Looked around and seems pretty widespread. Links below to many issues, and some now fixed partially. Yeah, let's hope the open sourcing of those drivers make for a brighter future, but still I will do my damned best to never buy an nvidia product again.
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
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.
I did a session with my colleague now: MacOS client, Ubuntu server. Got a couple disconnects too - but felt like they are very close to having an awesome product.
“You have full control of your data, with no concerns about security”
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.
In fact, in the pursuit of eliminating memory-safety and security bugs, Rust can sometimes makes some privacy bugs more likely.
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.
> [...] just hold a reference to the UserAccount itself and modify it at will without any confusion
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.
That's why I mentioned one needs to have discipline, to not use that particular solution.
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.
In Rust, people tend to go for the easiest solution that works within the borrow checker, and not workarounds like Rc or Arc. Otherwise, the performance hit means there's little reason to use Rust over much easier languages.
Callinc Rc a workaround is like calling i64 a workaround. It is a type that encodes a certain contract, it's there to be used. The advantage Rust has is that for 95% of your codebase the simple code using stack allocated values and references will be as fast as it can be, and yoi opt-into the slower behavior for the remaining 5% if they are not part of your performance critical path. If it is, then you need to rearchitect things, like you would in other languages. But you can do so after meaauring.
You don't have to throw out the baby with the bathwater. A few Arcs to hold onto a Users metadata is hardly going to be in the critical path of the app.
That's where the discipline comes in: one has to know when it's okay to use the simpler approach (indices into a Vec), and when it's better to use Arcs such as to prevent privacy problems.
The point is that we disagree that indices into a Vec is the simple approach. It's much harder. It infects the entire code. Whereas just using a reference count is basically set and forget.
Storing the index of an item in a vector in an actual application (vs in some tightly bounded api of a small, purpose-built library used by said application) is highly non-idiomatic and would emit noticeable stink in any code review. It’s just too hard to remember to update all indices after removing an entry. I’ve seen this mistake made in C, C++, rust, C#, JS, and Python code bases and it is usually someone that hasn’t been around long enough to understand the implicit technical debt in certain approaches that would suggest such a thing, regardless of language.
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.
That's why I said one should have the discipline and practices in place to avoid this bug.
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.
Better than a hash map of ids/values is to use slotmap, a library that handles everything safely for you (with generation indexing and free lists behind the scenes).
To be honest, this seems like a bizarre choice. Rc<> would not only be more idiomatic, it seems like it would even be more ergonomic because you don't then have to worry about passing your whole Vec around everywhere you want to access one of its elements
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
Saying it's "idiomatic" isn't very actionable advice for people, the average programmer hears that and doesn't really know when to use Rc over other approaches. I also wouldn't say to always go with the most ergonomic approach, that approach can lead to code that is even slower than other languages.
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.
I don't think the average programmer would think to do the Vec indexing for this situation in the first place
> 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.
> 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.
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.
Good point. This is a case where the problem may be in part people's preconceptions about how Rust "should" be used. People sometimes feel like cloning or using references is somehow cheating, but I think if people let go of that idea, it would be natural for them to choose a Rc<RefCell<T>> for these long running operations, as it mimics what GC'd or RC'd languages do.
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.
> Each has its own performance hit but that hit can be worth it
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.
I don't think that statement refers to rust at all. It's just referring to the fact the software is open source and the user's data doesn't go through a third-party
It was. There has been a time, when many people thought Macs were inherently safe systems, just because there was way less malware for it, than for windows.
Rust is really bad for security. It puts debug strings and full source file paths inside binaries. It's been a bug for over 5 years that's been reported and there's been no progress. Nobody talks about this wild dataleakage. Also leaks usernames on computers and such. This can lead to ALOT of forensics information and be used by authoritarian nations to find and arrest people for making software. I really don't think any rust application can meet some compliance requirements for certain sectors due to this either. But the developers and communities just wash this and other real issues under the rug.
Putting full paths in binaries is very common even in C++ projects. It's difficult to completely avoid and trivial to mitigate. In fact if you're doing things correctly - i.e. using CI & CD, there's nothing to do.
The only path in a C++ release build is the PDB or debug information. This can be removed with a compiler flag. The only other indicator is a timestamp, which again can be modified with a compiler flag.
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.
The North Korean dictatorship developed a linux distribution that adds machine and user identifying information to every single file to find whistleblowers.
Yep, it's a real threat to security, whistleblowers and even an organizations cyber security posture. I'll post a few strings which is enough for a state like North Korea to lock someone up for life. For example by just running strings on this binary. I find out the authors name is Zhou from.
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.
No? The goal posts were very clear. North Korea intentionally adding fingerprints to their users' documents is obviously not the same as compilers accidentally leaving them in.
Yes, you can verify that it doesn't work by looking at godbolt. Here's a very simple example. https://godbolt.org/z/sqW8xcGEc . For some reason everyone seems to suggest that when it's a currently open (For the last 5 years) issue on their github of it not working. Using a third party tool and binary patching is not an appropriate measure of securing a binary in the case of the linux strip util.
The default hasn't been changed yet (and if you look at the tickets there's ongoing conversation), but you can use `--remap-path-prefix` today if you need it.
That's good for the path. But there's still concern with the filenames being there, along with being mapped to specific functions. Filenames can be relatively unique and makes signature matching extremely easy. So it can still cause issues to people who have to worry about authoritarian regimes, as it's not out of the realm of this being enough evidence to arrest someone for having all the filenames.
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.
With VNC and RDP you have to mess with IP addresses, network configuration, quality/bandwidth settings, etc., which is a tall hurdle for general remote tech support. With TV, the other person simply shares a code, and the connection is much more stable.
I guess "remote support tool" would be the generic term. VNC and RDP are broader tools for controlling another computer and aren't specifically geared toward situations where someone without much experience wants to give the person supporting them control. (You could build a tool like that on top of them, probably.)
you can use their web version if you are in a pinch and have rusdesk client running at your home/office machine. since you know the password, you can get access quickly...
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.
Another option if you don't mind running your own server is Mesh Central. It's open source as well. I've personally met the developer and he's a very knowledgeable and likeable person, if that means anything.
I use XVNC / Remmina and the default RDP thing on macOS as a client when I'm remotely tinkering with my own machines. Is there something better that works for other folks?
as someone who has started to daily drive rustdesk for 12 hours a day 6 days a week on 1 to 5/9 computers daily, this is a much better experience visually than anydesk.
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
I also daily drive Anydesk, and I use it a borderline obscene amount. I have gotten no warnings about hitting a usage limit. I moved to Anydesk for the same reason, and would probably move away if Anydesk put up a payment wall. Do you have any links about free-tier limitations? I use Windows/Linux to connect to Windows/Linux/Mac/Android and I have not yet hit any snags with numlock or device connection limits.
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.
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
I most definitely use it a LOT more than that and have never hit an issue, but it's good to know there's a whitelist if that did happen. Thanks for the link!
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`.
It's just a phase in the language adoption, I think. It's still novel to write projects in it (though less so every day) and people are still out there "marking their territory" in it.
I think it makes more sense for interpreted languages. The program written in Python is always tied to Python. But a language that compiles to a native binary just happens to have source code in some language. Once it's compiled though, it's just a binary.
Pretty uncharitable and somewhat harsh indictment from you IMO.
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?)
Agree 100% on the benefits of Rust generally, and the overall quality of the new breed of tooling that's being developed. I too strongly prefer things make in Rust.
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.
Yeah I agree the naming is goofy and comes across as hacker-y and not user-friendly, maybe. I guess we the programmers generally suck at naming things? :D
Sure, fine, if that works for you, that's all good. FWIW I also make a living working in Rust right now.
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.
Because the language has a rather unique selling point.
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 think if it’s compiled binary, for me, that naming is less useful.
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 language has a unique selling point, I'm not sure many will know those advantages outside of the Rust community.
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.
For connecting between two Windows machines, I want to use the RDP protocol, but the built-in RDP client and server don't take care of the NAT/firewall traversal and such. Is there a software solution like TeamViewer or RustDesk that just does the leg work to set up the connection and then hands it off to the Windows built-in RDP libraries?
> The open source TeamViewer alternative. Display and control your PC and Android devices from anywhere at anytime.
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.
> There's no way any open-source project could compete in this space.
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.
Actually, yes, that's exactly what RustDesk does. Run the exe, get an ID and password, bypass all NATs, just like TeamViewer.
After TeamViewer decided I was a commercial user for some unknown reason and started blocking my sessions, I've used it with less technical friends and family several times without any significant issues.
To compete in this space is its main purpose and I'd say it does a pretty good job.
Well, the space is remote support and assistance, not "using it several times with family and friends", we already have a bunch of tools for that.
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.
You shouldn't need a M$ signed driver for capture, what makes you say that? I don't think it does a great job in the position it's in now, but it's hard to say it's not at least covering most of the big points that TeamViewer does, which qualifies it as an alternative.
RustDesk does have a quick connect style runner like TeamViewer that works just the same. It wasn't super performant, and on Windows it did not gracefully handle UAC prompts, so it definitely has some rough edges, but it functions much like its closed source predecessors did early on in its life.
What would stop someone from setting up a server that listens for connections? Kind of like a reverse VNC (or, by extension, reverse ssh tunneling). It may not be a feature of the program yet, but that doesn't mean it isn't possible. I could compile and distribute my own binary that automatically connects to me.example.com:1234, make sure that server is accessible from the internet, tell the user to bypass non-signed executable restrictions, and we're good to go.
This has been happening for very many years now. It is very common for a shady scam company to buy an enterprise license for remote access software preconfigured to allow unattended access via predefined variables. This is something very very useful in actual enterprise scenarios where you want to deploy remote access software, but equally dangerous in the wrong hands. The only thing you can do to stop it is educate end users.
