Hacker News Reader

Comment by brcmthrowaway | Hacker News Reader

I would like to use this comment to mention Parsec. It's unbelievable how much snappier it feels compared to the default Screen Sharing. What is their secret sauce?!

I just wish it didn't require an internet connection for authentication

View on HN

Try Moonlight, similar tech but open/no cloud auth. Works better over local networks though as opposed to internet (which you need to set up via vpn/portforward etc)

Sadly seems to be NVIDIA/PC? only.

This bummed me out, but it looks like it's not? From the Sunshine (server) GitHub page[1]:

  Sunshine is a self-hosted game stream host for Moonlight. Offering low latency, cloud gaming server capabilities with support for AMD, Intel, and Nvidia GPUs for hardware encoding. Software encoding is also available.

1: https://github.com/LizardByte/Sunshine

I think it was originally all NVIDIA proprietary, then got reverse engineered OSS client(Moonlight), then got RE'd OSS server(Sunshine).

I have it running clean and crisp hosted off an old i5 SFF HP G2 mini slice with integrated Intel graphics so give it a try!

Sunshine/Moonlight are awesome, but fwiw in this specific context it's worth noting that macOS support with Sunshine is still extremely experimental and janky. It's Homebrew only for now, and when I tried it out last the main release didn't install at all, only the beta. And then locally even over a 10 gig network while the image quality was great the latency was abysmal, even before other oddities. I will say this is enormous improvement over even a year ago, but given the initial gaming focused use case I suspect that (not at all unreasonably!) they've prioritized client capabilities when it comes to Macs for now.

Last I looked, they didn't support passing through USB devices like Wacom tablets or edit controllers or space mice. I am eager for that stuff to work so that I can start using moonlight/sunshine for more of my work.

On gpu encoding/decoding of the frame buffer

Is there a free alternative to Screen Sharing that is more performant? I'm just surprised at the latency and cpu usage of Screen Sharing on my lan. (Mac specific)

NoMachine

Just don't. It is janky and buggy and keeps coming up time and time again, but it is not a real solution.

Yeah. I tried it but audio bugged out after a while for seemingly no reason. Very janky software, should be a last resort.

Is it really just authentication? I thought the whole screen data was passed through an intermediate server, but I can see how a peer 2 peer system would be more efficient. I can't imagine the wonky NAT hacks that need to take place though.

How would it not require an internet connection lmao, it's a remote connection tool

I think op meant cloud based in the sense you have to create a user account on their site and everything goes through that.

Remote desktop between computers on a local network

I guess, but I thought the selling point of parsec is that it reduces lag (or hides it).

This would make sense in VPN environments though.

>How would it not require an internet connection lmao, it's a remote connection tool

I'm kinda surprised you've managed to be on HN for 5 years and never come across the concept of a "LAN" or "VPN" before, but I guess you're one of today's lucky 10000. To the first, sometimes you have machines (or VMs) local to your own network but in another physical location that you'd like to be able to access from your own system. It's a fairly significant use case, and one where no internet connection is involved whatsoever. For example it's generally desirable to locate powerful (and in turn generally loud) servers and associated gear (including environmental control, redundant power etc) in physically isolated locations from where the humans are working for noise reasons if nothing else, though security and efficiency are important as well. While it's possible to pipe raw video over IP, a quality remote desktop solution will generally be more flexible/scalable and doesn't require special (expensive) extra hardware and potentially additional fiber.

And for systems located on other LANs remote from your own, you can use a VPN to link them securely as if they had a direct physical (though higher latency/more jittery) link, again avoiding any exposure to the public net. That then reduces to the above. In both cases it's desirable to have zero unnecessary 3rd party dependencies.

> I'm kinda surprised you've managed to be on HN for 5 years and never come across the concept of a "LAN" or "VPN" before

Unnecessary snark.

It's not snark, in your reply you for whatever reason cut out the context at the end of the sentence. "Lucky 10k" is referring to this xkcd comic [0] which I thought was a pretty good one and I've tried to take to heart. I was genuinely surprised, but that's the point, what one thinks is "common sense" or "everyone knows" is always going to be brand new to someone every single day. It's happened to me lots, and is one of the delights of HN, to learn about a whole new set of use cases you've never considered before. In this case maybe it will lead them to consider how it might be useful in their own offices or homes for that matter. Making a powerful machine run quietly is both challenging and can be fairly expensive. But if you have the physical space available, then you may be able to just use powerful, cheap loud fans by virtue of putting it in an area of a basement or the like away from living space/home office and accessing it remotely. Depending on how you do so the quality can be the same as if you were sitting in front of it.

----

0: https://xkcd.com/1053/

No reasonable person interprets the original comment as someone not knowing about the existence of a LAN, hence snark.

Turnabout is fair play to the comment OP.

Ah you got me I guess, didn't think of the VPN case. It does seem like an asterisk in the grand scheme, especially since the applicability of this tech in LANs is very limited (there's no lag in LAN, and it's already internet in the sense that it uses IP, you would need to consider an ethernet framing tool or a unix socket tool like X11 for truly local-remote protocol), so this would only useful in this network-virtualized VPN ecosystem (and also in scenarios where you want to ensure no third party handles the data, by self hosting the server part of parsec)

What is clear to me is that Parsec belongs to a newer breed of remote tools, inline with TeamViewer and AnyDesk, that primarily respond to the need of post ISP firewall era, where by default ports are blocked, so peerless remote tooling becomes harder to install and administer, these have a client-server-client based architecture. And Parsec builds upon this architecture by placing some secret lag reducing sauce on their Server instead of just authenticating and forwarding.

My guess is that they have a proprietary predictive and interpolation based OS algorithm tightly coupled to the OS UI, and this secret sauce lives and is closed source on their backend, so you would kind of need to host a third server in the middle, maybe we will see a competitor for a VPN niche, or an open source alternative.

If an open source solution arises, I bet that it would require an installation of a server, and it would probably start with X11 or Wayland tight coupling.

Cloudless Fluid requires a Teams Enterprise subscription. Or one can manually enter IP addresses. Their default is cloud mediation, so yes, they presume a working internet connection.

Reply on news.ycombinator.com