Live data from Hacker News

RustDesk now supports true unattended remote access on Wayland

rustdesk.com

161–170 of 176 posts

Re: RustDesk now supports true unattended remote access on Wayland

#161
post #140
post #18

RustDesk still does not support encrypted connections when self hosting: https://github.com/rustdesk/rustdesk/issues/3714

> RustDesk still does not support encrypted connections when self hosting Not true at all. RustDesk connections are fully encrypted even when using a self-hosted server. What is not supported are encrypted direct endpoint-to-endpoint connections not going through a server at all, because that's not a use case RustDesk is designed for. The feature is intended for testing, which is why it's disabled altogether by defau…

So, to have end to end encryption you need to do something like:

Client -- Relay Server -- Host

That's certainly less than ideal since many remote desktop session will not be using a middle-age server but rather be direct between client and host.

Re: RustDesk now supports true unattended remote access on Wayland

#162
post #38

Earlier quoted context omitted.

> Rustdesk is considerably more performant than the VNC family It consumes, on the client, 800%-1200% CPU AND 8%-10% GPU decode on my NVIDIA card. I opened a bug and they transformed it into a discussion, without any response.

Performant does not mean it uses less resources, it means it makes better use of the resources

Better is subjective. What is the bottleneck or resource allocation you're trying to overcome?

Going on what the poster above says about CPU and memory - if the network speed or bandwidth allocation is the bottleneck, then trading CPU and memory utilisation increases for lower bandwidth is likely acceptable. If, however, the device is low end and tying up memory and CPU with compression would lead to sluggish or impaired task performance but the network has adequate overhead for lower levels of compression or higher levels of data transfer then higher network utilisation would be preferable.

Different tools, different use case scenarios.

Re: RustDesk now supports true unattended remote access on Wayland

#163

Earlier quoted context omitted.

> That's is a statement of truth though? "Many ask, none provide, you want it, you contribute it" seems to be the vibe, which is completely understandable and also expected in FOSS. It's not hostile or shaming for the sake of shaming. I understand a lot of projects take this attitude but that doesn't mean it's always deserved. > Yes, I guess you can see it as "shaming", but no I don't think it's bad. Users ask for st…

> Here, they aren't agreeing with it whatsoever Yeah, that's the core difference in our readings I think, the mere fact that they say openly they welcome someone contributing the feature, does mean they agree with it, why offer to accept such a contribution otherwise? Are they lying/not being honest, and the PR would just sit there without being accepted. It's clear you think so, and it does feel like you have past e…

They say they welcome contributions in general and that users generally don't submit PRs to go with their feature requests. They don't say they will accept a PR for the specific feature or that they want one. As much as it may seem obvious, it's technically not what they said.

> It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your past experience, so I don't know, but hits me as strange to ask for contributions for a feature you don't actually want, I don't understand why'd they do that.

I was a member of a discussion I linked in another comment about password complexity requirements, but I do not have experience with raising other issues or trying to get features accepted, so none of this is a simple grudge, just a very pedantic reading of their response.

I do have experience with manipulators that use exactly this kind of language to make good implications that they don't actually intend to honor. (Including myself at points.) So maybe my reading is unnecessarily pessimistic, but it's not based on some prior experience with them, just the particular way they made their statement.

Re: RustDesk now supports true unattended remote access on Wayland

#164
post #38

Earlier quoted context omitted.

> Rustdesk is considerably more performant than the VNC family It consumes, on the client, 800%-1200% CPU AND 8%-10% GPU decode on my NVIDIA card. I opened a bug and they transformed it into a discussion, without any response.

Performant does not mean it uses less resources, it means it makes better use of the resources

Please detail in what ways rustdesk "makes better use of the resources", so as to conclude that it is more performant. I'm curious to understand your perspective, since mine is very different.

Re: RustDesk now supports true unattended remote access on Wayland

#165
post #164

Earlier quoted context omitted.

Performant does not mean it uses less resources, it means it makes better use of the resources

Please detail in what ways rustdesk "makes better use of the resources", so as to conclude that it is more performant. I'm curious to understand your perspective, since mine is very different.

I honestly don't have the experience to speak on whether it's actually more performant or not, since I don't trust networked screen sharing (I use a wired capture card exclusively). The only time I ever use networked remote desktop is when I can't be bothered to hook up the cables, or when I'm not physically close to the machine.

However, I would say that high CPU or GPU usage is not necessarily an indicator of bad performance, especially since higher utilization can mean better performance.

Re: RustDesk now supports true unattended remote access on Wayland

#166

Is there a reason to use this over something like Sunshine/Moonlight?

rustdesk just works, moonlight and sunshine is janky as hell outside the local network due to the fact it uses like 5 different streams.

I have never once gotten rustdesk to work. I don't try anymore.

Re: RustDesk now supports true unattended remote access on Wayland

#167

Earlier quoted context omitted.

> Here, they aren't agreeing with it whatsoever Yeah, that's the core difference in our readings I think, the mere fact that they say openly they welcome someone contributing the feature, does mean they agree with it, why offer to accept such a contribution otherwise? Are they lying/not being honest, and the PR would just sit there without being accepted. It's clear you think so, and it does feel like you have past e…

They say they welcome contributions in general and that users generally don't submit PRs to go with their feature requests. They don't say they will accept a PR for the specific feature or that they want one. As much as it may seem obvious, it's technically not what they said. > It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your pa…

> They don't say they will accept a PR for the specific feature

Again, to me it's 100% clear they would accept a PR, but I guess there is nuance in "we welcome community contributions" and "your PR would be greatly appreciated"...

Also again, obviously you've already made up your mind. But as the perspective of someone who never interacted with the project, the impression (based on their words) is that they'd like a PR for this feature.

Besides "they don't intend to honor it!1!" which is essentially a guess, do you have any previous cases where they actually explicitly said they'd accept a contribution and then they dragged their feet accepting it/rejected it?

Re: RustDesk now supports true unattended remote access on Wayland

#168
post #140

Earlier quoted context omitted.

> RustDesk still does not support encrypted connections when self hosting Not true at all. RustDesk connections are fully encrypted even when using a self-hosted server. What is not supported are encrypted direct endpoint-to-endpoint connections not going through a server at all, because that's not a use case RustDesk is designed for. The feature is intended for testing, which is why it's disabled altogether by defau…

So, to have end to end encryption you need to do something like: Client -- Relay Server -- Host That's certainly less than ideal since many remote desktop session will not be using a middle-age server but rather be direct between client and host.

”Many?” Teamviewer does not work like that which by far is the most popular.

Re: RustDesk now supports true unattended remote access on Wayland

#169

Earlier quoted context omitted.

They say they welcome contributions in general and that users generally don't submit PRs to go with their feature requests. They don't say they will accept a PR for the specific feature or that they want one. As much as it may seem obvious, it's technically not what they said. > It's clear you think so, and it does feel like you have past experience with the project so I guess that is what it is. I don't have your pa…

> They don't say they will accept a PR for the specific feature Again, to me it's 100% clear they would accept a PR, but I guess there is nuance in "we welcome community contributions" and "your PR would be greatly appreciated"... Also again, obviously you've already made up your mind. But as the perspective of someone who never interacted with the project, the impression (based on their words) is that they'd like a…

I think we should agree to disagree here -- I read their comment and it says they generally accept contributions, but nothing about the specific contribution. You read their comment and it looks perfectly clear to you that they're looking to accept the specific contribution.

Re: RustDesk now supports true unattended remote access on Wayland

#170

Earlier quoted context omitted.

I just have envoy proxy with the oauth + jwt filter in front of those services. Envoy does the oidc flow with pocket-id so I can use passkeys for authN. Envoy validates the resulting token and does authorization via ACL. Envoy then sends an authorization bearer jwt with the oidc id_token jwt to the backend (for example grafana). Grafana parses and validates the jwt and sets claims as userinfo (username, groups, email…

It's funny you say that, as one of my weekend projects today is setting up https://www.authelia.com/ to achieve the same. I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.

You can use the great oauth2-proxy as a forward auth proxy to archive that if you use nginx btw, i did that before envoy.
Post reply on HN