Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm sure it will only be a matter of time before somebody builds an open-source app for this service and turns it into a general-purpose remote desktop service. Hopefully the RPi Foundation doesn't get so much illegitimate traffic that they have to shut this down, as it's a neat idea.


Apache Guacamole is FLOSS actually, RustDesk as well, while not much known they do offer such service already, Guacamole as a web-desktop, RustDesk as a classic desktop sharing app.

But honestly we do not need this paradigm, we do need file sharing and syncing in a classic real desktop paradigm. Remote desktops are a kind of new dumb terminals and mainframe model, useful for people that can't really work remotely.

Just as a personal experiment I've tried a different distributed enterprise work model:

- employees receive a new desktop at home, not a laptop, empty storage media AND a usb stick with a self-installing ciphered live distro, they get the key from other media, there are various options like "after you get the iron write down the serial on it and we reply back with the key" or direct paper mail and so on;

- they mount their work desktop in their own work desk, plug the USB and first boot. The live image auto-install and offer a recovery desktop environment with SSH (reverse proxy) and remote desktop (RustDesk for instance) so in case of trouble they can receive support even at this stage;

- they boot their newly installed system and it start syncing relevant data form company servers;

- they works locally as much as possible syncing back data to the company as frequent as possible, of course certain dataset can't be locale because of the size etc, but most users do not work on such large/high-bogomips stuff, the rest is typically some WebApp. Local systems are FDE and demand a smart-card and it's pin to log in;

- a spare machine can be delivered NBD and similarly deployed, the broken one being FDE can be sent back issueless, data sync avoid the employee running away with valuable stuff, oh, yes, nothing can stop him/her to copy company data and do nasty things with them but... It's not really different in an office. If you can't trust your employee and still need to give them complete usable data there is no IT protection, you can act only at human level.

Well, the above is a simple dumb paradigm but the purpose is just showing that:

- we need to have IT match company structures/human life

- we need to be resilient not creating more SPOF

- it can be done with what we already have, it's more a matter of habit then tech


They’d still need to host servers somewhere.


With WebRTC, aren't the servers just used for initial handshake/signaling? The rest of the traffic would be P2P so not a lot of capacity needed except for the initial handshake.


FTA:

> "Our intention is that Raspberry Pi Connect will remain free (as in beer) for individual users with non-relayed connections, with no limit on the number of devices. We don’t yet know how many people will need to relay their traffic through our TURN servers; we’ll keep an eye on the use of bandwidth and decide how to treat these connections in future."

So yes it is possible to only provide servers for the initial connection / negotiating the best direct path between server and client; but they expect some non-zero percent of connections to need to actually have the whole thing going through their servers, and an open source software that doesn't offer that would therefore not be able to support that portion of usage.

edit v2: my original edit was too verbose to be worth keeping, I think, so I'll just write a TLDR of the idea below and if you want to read my rambling 600 word elaboration that I'm too lazy to rewrite more concisely it's here: https://pastebin.com/67iQQvtC

Dynamic DNS service of some kind could be responsible for making sure the client can always reach the server's latest public IP, with the following options:

1. DDNS hosted on server by the open source tool (i.e. abandoning the no server needed hope)

2. Using using an existing free DDNS service (potential trust issues)

3. Users providing their own domain for DDNS, hosted by a domain provider with API functionality for changing A records so that the new remote desktop tool can do that directly

4. Finding a domain provider who offers such granular API access that the open source tool could own a single domain, and allow many people access to update over the API their individual subdomains, or sub-subdomains (but even if you can find one that technically offers this kind of API access, they might not be happy with someone paying for a single domain and then letting thousands of users all have individual API keys sending updates any time their public IP changes...)


They offer a tunnel when connections cannot be established. But beyond that someone has to host it. Why not RPi foundation? I have no reason not to trust them, especially when they make the device itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: