[HN Gopher] RustDesk - Open-source TeamViewer alternative
___________________________________________________________________
RustDesk - Open-source TeamViewer alternative
Author : swah
Score : 211 points
Date : 2022-07-26 14:46 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| IYasha wrote:
| Nah, when it comes to Linux, KRDC wins.
| fareesh wrote:
| 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?
| Demonsult wrote:
| NoMachine uses hardware h264 encoding. I can watch youtube
| remotely and barely notice the difference.
|
| It's commercial software with free personal use.
| naikrovek wrote:
| an open source thing like nomachine would be wonderous.
| swah wrote:
| Is the initial connection as easy as TeamViewer - ie share a
| code with ther other person?
|
| I feel like that's the main thing when talking about
| "TeamViewer alternative": not needing to setup external access
| / port forwarding on your router.
| xen2xen1 wrote:
| Mesh Central is the other decent open source offering I know
| of.
| legalcorrection wrote:
| 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?
| easrng wrote:
| Try the built in Quick Assist app? I think it does NAT
| traversal.
| chungy wrote:
| As someone that's never used TeamViewer, is that a more complete
| description than simply being a "TeamViewer alternative"?
|
| 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?
| actuallyalys wrote:
| 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.)
| imiric wrote:
| 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.
| 2Gkashmiri wrote:
| 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.
| shimonabi wrote:
| I have tried self-hosting this with Docker a couple of weeks ago
| and it seems to work.
|
| 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.
| e12e wrote:
| > Be careful: encryption is not enabled by default.
|
| Wait, what?
| aantix wrote:
| Is it common in the Rust community to include the name of the
| language as part of the application name?
|
| Reminds me of the early 2000's - phpBB, etc.
| [deleted]
| cmrdporcupine wrote:
| 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.
|
| Python had a similar phase.
| pdimitar wrote:
| 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?)_
| cmrdporcupine wrote:
| 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.
| pdimitar wrote:
| I agree that it's a techy branding, absolutely.
|
| 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.
| vlunkr wrote:
| Maybe you disagree with them, but I have a hard time
| finding anything harsh about that comment. It's just their
| opinion on the phenomenon.
| switchbak wrote:
| 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.
| pdimitar wrote:
| 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
| teawrecks wrote:
| 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.
| Fnoord wrote:
| 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 actually find it useful as its descriptive.)
| aantix wrote:
| 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.
| aantix wrote:
| 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.
| adadtttt wrote:
| Does it support hardware accelerated video encoding like parsec?
| Looking for an alternative that performs similarly.
| sascha_sl wrote:
| If your host has an NVIDIA GPU, Moonlight arguably performs
| better than Parsec on stable networks.
| BitPirate wrote:
| https://github.com/rustdesk/rustdesk/issues/589
| dainiusse wrote:
| Tried it with my mom. With no negativity as I know it is not easy
| to make. But it would freeze after 15s of shared session time
| swah wrote:
| 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.
| jupp0r wrote:
| "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.
| moldavi wrote:
| 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.
| actuallyalys wrote:
| 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.
| brundolf wrote:
| 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
| moldavi wrote:
| 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.
| brundolf wrote:
| 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.
| estebank wrote:
| > 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.
| ComputerGuru wrote:
| 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.
| gpm wrote:
| 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).
|
| https://crates.io/crates/slotmap
| moldavi wrote:
| 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.
| DenseComet wrote:
| > 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.
| spullara wrote:
| GCs rarely do something as expensive as Arc.
| estebank wrote:
| Barring a JIT, either they do _or_ they have thread
| unsafety.
| jeffparsons wrote:
| > [...] 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.
| moldavi wrote:
| 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.
| rowanG077 wrote:
| Arc is by far the easiest solution. You don't have to
| deal with indices at all.
| moldavi wrote:
| 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.
| estebank wrote:
| 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.
| rowanG077 wrote:
| 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.
| moldavi wrote:
| 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.
| rowanG077 wrote:
| 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.
| [deleted]
| lagrange77 wrote:
| Ok fair point, but if run it additionally on a Mac, you should
| be completely safe.
| etskinner wrote:
| What does running it on Mac have to do with avoiding non-
| memory-safety bugs?
| hkwerf wrote:
| That may have been sarcasm.
| lagrange77 wrote:
| 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.
| [deleted]
| geophertz wrote:
| 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
| maldev wrote:
| 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.
| IshKebab wrote:
| 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.
| maldev wrote:
| 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.
| IshKebab wrote:
| > In authoritarian countries where people have to worry
| about security services, this is a big threat which can
| get people killed.
|
| Pure paranoia. Find me one instance ever where anything
| like this has happened.
| eska wrote:
| The North Korean dictatorship developed a linux
| distribution that adds machine and user identifying
| information to every single file to find whistleblowers.
| eska wrote:
| Did you call "strip" on the final executable?
|
| It is now also possible to specify "no debug info" for the
| release build in the build config.
| estebank wrote:
| For reference, the tickets GP is talking about are
|
| - https://github.com/rust-lang/rfcs/pull/3127
|
| - https://github.com/rust-lang/rust/issues/40552
| maldev wrote:
| 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.
| estebank wrote:
| 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.
|
| https://godbolt.org/z/zTh36c6Pz
| maldev wrote:
| 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.
| 2Gkashmiri wrote:
| 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
| Technetium wrote:
| 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.
| 2Gkashmiri wrote:
| yeah, there is a soft-limit
|
| 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
| Technetium wrote:
| 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!
| ComodoHacker wrote:
| > 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.
| belthesar wrote:
| 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.
| arsome wrote:
| 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.
| ComodoHacker wrote:
| 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.
| Technetium wrote:
| 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.
| imiric wrote:
| > 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.
| etskinner wrote:
| 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.
| vxNsr wrote:
| Yea this is likely what we're gonna see in scams in the
| coming months, years, go to helpmenow.com download/install
| look at that you're scammed.
| Technetium wrote:
| 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.
| Technetium wrote:
| 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
| BitPirate wrote:
| Controlling a wayland client on Linux is still work in progress:
| https://github.com/rustdesk/rustdesk/issues/56
|
| Partial support has already been added:
| https://github.com/rustdesk/rustdesk/pull/932
| ChuckNorris89 wrote:
| 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.
| badsectoracula wrote:
| 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)
|
| [0] https://en.wikipedia.org/wiki/GPD_Win
|
| [1] https://github.com/Plagman/gamescope
| vetinari wrote:
| > 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.
| ledgerdev wrote:
| I have a laptop with nvidia card and wayland runs fine on the
| laptop screen, but lots of problems with docks and external
| monitors.
| nicce wrote:
| Wayland should be superior on external monitors when
| compared to Xorg, what kind of issues?
| gpm wrote:
| I'm struggling to imagine how it could be superior to
| Xorg on this... Xorg works flawlessly with external
| monitors in my experience.
|
| Maybe there's some edgecase that I haven't hit that it
| fixes?
| nicce wrote:
| Monitors are thought as separate instances by design when
| compared to Xorg. You can run different FPS on different
| monitors on Wayland, for example.
| vetinari wrote:
| > Xorg works flawlessly with external monitors in my
| experience.
|
| Unless your displays are mixed DPI.
|
| Wayland works much better in this scenario.
| ledgerdev wrote:
| 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.
| nicce wrote:
| It sounds like a driver issue and hard to say what is
| wrong...
|
| 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...
| tendstofortytwo wrote:
| 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.
| jnsaff2 wrote:
| 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.
| nicce wrote:
| 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.
| beebeepka wrote:
| What hardware, though? Do you have a dGPU, play games, etc.
| We know it works for "desktop" use
| larschdk wrote:
| 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).
| nicce wrote:
| Two years ago, the support was added?
|
| 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...
| stoplying1 wrote:
| revolvingocelot wrote:
| 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.
|
| ...right?!
| stoplying1 wrote:
| kingrazor wrote:
| 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.
| benbristow wrote:
| 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).
|
| https://www.zerotier.com/
|
| Works really, really well and doesn't try to wrongfully block me
| for 'commercial usage' like Teamviewer does.
| ProtoAES256 wrote:
| 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.
| password4321 wrote:
| Bitvise SSH Server for Windows is also free for personal use,
| if you'd rather just forward the RDP port securely.
| vetinari wrote:
| RDP nowadays uses TLS.
| password4321 wrote:
| True! My recommendation is influenced by 2019's
| https://en.wikipedia.org/wiki/BlueKeep Microsoft RDP remote
| code execution vulnerability.
| benbristow wrote:
| 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.
| archi42 wrote:
| 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.
|
| [1] https://askubuntu.com/questions/48129/how-to-create-a-
| restri... Check the accepted answer.
| thebeardisred wrote:
| I'm a bit curious here.
|
| 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?
| NoraCodes wrote:
| It's a stated goal to replace sciter with Flutter.
| proto_lambda wrote:
| Quoting from the last time this was posted
| (https://news.ycombinator.com/item?id=31456007):
|
| 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`.
| [deleted]
| Fnoord wrote:
| Came here to comment on Wayland (I don't use Gnome or a display
| manager but Sway fired up from CLI). I guess I will keep using
| wayvnc over Wireguard.
___________________________________________________________________
(page generated 2022-07-26 23:01 UTC)