Raspberry Pi Connect
raspberrypi.com
raspberrypi.com
EDIT: Actually for that matter I can't see why this is arm64-only; AFAICT everything it needs should run fine on 32-bit. I wonder if this is just a minimal first version?
Also, I can't find any confirmation - is all of this open source or not?
Secondarily, I would wonder if older/32-bit devices might not end up being a little too resource-constrained to be either a bad customer experience (driving more support load), and/or making development too costly.
Besides, if you have x11, you can still use RealVNC.
True, although if you already have wayvnc that's like a day of work; AFAICT x11vnc and wayvnc are nearly drop-in replacements.
> As the goal is to move away from X11, it doesn't seem likely that they would invest time into that.
It may be the goal, but is it the present? All the articles I can find about the pi transition to wayland say it's the default for the pi 4 and 5 but not anything else. Which is consistent with
> First of all, Raspberry Pi Connect needs your Raspberry Pi to be running a 64-bit distribution of Raspberry Pi OS Bookworm that uses the Wayland window server. This in turn means that, for now, you’ll need a Raspberry Pi 5, Raspberry Pi 4, or Raspberry Pi 400.
but raises the obvious point that supporting X11 would be helpful to support earlier models. (Along with 32-bit support, which I also am surprised at them not including.)
> Besides, if you have x11, you can still use RealVNC.
And if you use wayland, you could just use wayvnc directly. The whole point is to wrap it up in a nice package and add just enough central server to deal with connectivity.
1. It's ancient, and was made for the graphical requirements of computers from a time before Windows 2.0 even hit shelves. Go back and look at Windows 1.0 - that's the kind of graphics this was made for.
2. Almost nobody understands the code. The contributors have openly said they are probably the only dozen people who could ever work on it.
3. Those contributors hate the job, and have basically abandoned Xorg since 2018, with only one minor release in 2021. Xorg is nowadays abandonware. It still works - but it's still abandonware.
4. X11's design was feature creep from the very beginning. At one point it even handled printing before CUPS was invented and that part was ripped out. The fact that it tried to be many things at once, then was "simplified" into "only" being a graphics server, has caused the code to be abysmal [https://www.x.org/archive/X11R6.9.0/doc/html/Xprt.1.html].
5. Nobody knows how many security vulnerabilities are in X11. When you have a decades-old codebase in C, anything can happen - especially when for most of the time, it was never fuzzed or testable. In 2013, just one security researcher found over 120 bugs in just one part of X11 (GLX) [https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291...]. Just last year, two major security bugs were found, both dating back to February 1988 [Note 1, https://lists.x.org/archives/xorg/2023-October/061506.html].
6. Criticism of Xorg as being an extremely flawed design is not new, or even a criticism because we have modern devices. Even in 1994, scathing reviews were well known. https://web.archive.org/web/20091111071410/http://www.art.ne...
It's time to move on. Yes, some things will be lost. That's the cost of progress. We lost the ability to run 16-bit DOS programs decades ago. Ironically, X11 is older than many DOS programs.
[Note 1] Living proof that "open source" does not necessarily mean "more secure," especially when the source code is so complex that "security by obscurity" becomes the actual security strategy. 35 years is older than many people in this forum.
In fairness to X, Wayland contributors seem to hate their jobs as well.
Some might say, "But Wayland breaks XYZ, or can't do XYZ!"
I'm just going to quote Adam Jackson, who was the project owner for X.org at Red Hat:
"I'm of the opinion that keeping xfree86 alive as a viable alternative since Wayland started getting real traction in 2010ish is part of the reason those are still issues; time and effort that could have gone into Wayland has been diverted into xfree86."
It is not "old"! It is "complete", "settled", and "stable". Not everything needs to be replaced and rewritten just because it is old.
"Programming X is like reading one of those French philosophers where afterwards you start wondering whether you really know anything for sure." - Thomas Thurman (GNOME developer)
"Wayland wasn’t designed to be a drop-in replacement for X11 any more than Linux was designed to replace Windows. Expectations need to be adjusted to reflect the fact that some changes might be required when transitioning from one to the other." - Nate Graham (KDE developer)
"Three people on this earth understand X input, and I wish I wasn't one of them." - Daniel Stone (Freedesktop Project)
"Let me summarize every wayland discussion on the internet: I'VE SEEN A WINDOW SYSTEM SO I KNOW HOW THEY SHOULD WORK PAY ATTENTION TO MEEEEEE" - Adam Jackson (former Xorg project owner, Red Hat)
And the classic 1994 criticism:
"If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles -- but you'd be able to shift gears with your car stereo. Useful feature, that." - Marus J. Ranum, Digital Equipment Corporation
In days of yore (when Windows 3 was young), there were even commercial X servers (Hummingbird I think it was), so there's plenty of other people implemented the protocol.
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
> "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...)
So not free as in Freedom, no source code?
Otherwise... the service uses wayvnc for the Pi server part, and you could replicate the setup with TigerVNC easily enough over local LAN or through a VPN. The Pi Connect service is the hosted backend; not sure what they're using there.
.deb file: http://archive.raspberrypi.org/debian/pool/main/r/rpi-connec...
It contains two Go executables in its /usr/bin path: rpi-connect and rpi-connectd.
https://opensource.stackexchange.com/questions/620/what-is-t...
But beer's recipe is open source, anyone can brew their own. It's a really bad analogy, it should be free Coca-Cola or something.
It's free, but you can't do anything you want with it. Really it's free to drink on my terms - and that's certainly "free", but it's not "freedom" (as in free speech).
Or, since it seems to need explaining, the point is that "beer" is not one thing with one recipe and if somebody offers you "free beer" it is pretty obviously a specific kind and batch of beer.
What I mean is that: You don't have a public IP, you likely go to the internet via a router. That router is stateful and allows traffic destined to go to some other internet address to return to you, even though your device is not technically routable on the internet.
So, what a STUN server does, is give you information about how to initiate connections to each party; that allows traffic to go through each of your routers.
CLIENT1 <-> STUN // (what ip/port combo is needed for CLIENT2 ;;; there is nothing in the table)
CLIENT1 <-> CLIENT2 // (initiate a connection attempt that will fail, but will be remembered by the stateful NAT/firewall for return traffic)
CLIENT1 <-> STUN // (CLIENT1's incoming info for CLIENT2, this combo will only work for CLIENT2, so it requires CLIENT2 to ask about it)
CLIENT2 <-> STUN // (what ip/port combo is needed for CLIENT1 ;;; information is now in the table and will be fetched)
CLIENT2 <-> CLIENT1 // (direct connection based on previous incoming connection attempt *from* CLIENT1)
TURN is the same idea, but instead of coordinating a peer-to-peer connection, it routes traffic via itself, it's just a neutral relay.
If the NAT is more restrictive then a TURN server can act as a middleman to relay the packets between device A and device B.
So it's a Pi Foundation hosted STUN. Basically a Zerotier clone, neat.
Wow, one relay server! A company with rpi size should be able to do better. The problem the latency might render it useless, just use wireguard.
That implies tracking. I'm not touching it.
* Does it not work on Raspberry Pi Zero W?
* Can I install and set it up in Pi Imager?Can this even be set up on a Pi over SSH without a graphical view of the Pi?
rpi-connect signin
This will give you a URL to copy and paste into a browser. Authenticate with your Pi ID, and then the Pi will be connected.
Do you think Raspberry Pi Zero Ws might get support eventually?
I guess the use case here is something like a remote workstation easily accessible from any device.
On unrelated note this is pretty cool service, considering how much effort it takes to properly setup vnc server together with novnc and nginx in reverse proxy mode properly configured with LE TLS certificates, local firewall and a port forward on a router.
You're the only one talking about it... but I mean yeah used x86 boxes do tend to beat a pi at price, performance, and software compatibility, and only lose at power consumption (unreliably, at that) and physical size.
Not even that. The J4125 box I have runs circles around my Pi4, was only 40€, and has a lower power consumptions (though at those levels the difference is mostly meaningless) The size is a huge difference, but as they are both in the living room cupboard (the Pi4 now runs Proxmox Backup Server), that doesn’t really make a difference for my case.
(I would however separate out unique applications with the RPI Zero given the form factor)
Pi Connect doesn't work on the Zero 2 W though ;)
EDIT: I should have taken a minute to check the Pi OS release notes:
> Desktop now runs on the Wayfire Wayland compositing window manager on Raspberry Pi 4 and 5 platforms; on X11 using the openbox window manager on older platforms
Are they really?