This is a problem that the GNU Guix package manager[0] (and presumably its inspiration Nix[1]) are helping to solve. Any two git checkouts of Guix with the same git hash on the same architecture should produce bit-identical builds across time and space for many of the programs it packages. It's not true for everything they package yet, but they're making progress.
This is true, but I think it's an important distinction that store cards are typically opt-in (I haven't come across a store that requires such a card to shop there, except maybe Costco). A facial recognition system would, presumably, be automatic.
They can and do enforce the real name policy. If they suspect your name isn't real (via algorithm or user reports) they will freeze your account until you send them scans of government ID confirming your name. I have a friend with an unusual name, and she's had to go through the process twice thanks to harassers flagging her.
This is a fairly significant and under discussed problem. Rush Limbaugh is probably safe from harassment... that dude commenting in some political group is not so immune. This creates an interesting chilling effect.
There are a few reports there of games on Unreal Engine 3 having graphical glitches and performance issues under 8.3. It looks like Unreal Engine 3 is not getting updates anymore[0], so it's possible that UE3 users are stuck. (I don't know if Spiderweb use UE3).
I would be very, very surprised if they were using UE3, considering their games haven't seen much of a graphical update since... 1994? Really old school in literally every single way. Think Ultima Online, then take a step back from that.
However, I wouldn't be surprised if they suffered from a similar regression.
As a quick word of caution (which doesn't invalidate anything you've said), Go has a long-standing bug[0] whereby syscall.Setuid doesn't always apply to all threads (on Linux at least) so extra care does have to be taken.
It's also a perfect example of why even really amazing teams reinventing a language/tooling ecosystem from scratch stumble over problems that were solved years (or even decades ago) in preceding platforms. I leave it as an exercise for the reader to decide if the "reinvent from scratch" critique is more deserved by Docker, Go, or Linux.
That being said, I'm pretty sure even the broken Setuid behavior described there would be good enough to sandbox a thread or child proc that was just handling buffered I/O into and out of the xz binary.
It's not a bug, strictly speaking; it's just a feature that's really easy to misunderstand. The `syscall` package in Go tends to be logic-less wrappers around the raw syscalls, and that's what happens here.
Linux actually maintains the uid/euid/suid/gid/egid/sgid/etc. fields per OS thread (which are actually processes, just with a bit of shared memory). The raw syscalls only change the fields on a single task.
Glibc is where the logic happens to propagate that setting to all threads, by setting up signal handlers and immediately triggering a signal, IIRC.
You can get the useful behaviour by using cgo and importing setresuid from unistd.h.
What go should probably do here is:
1) Add os.Set{res,re,}{u,g}id, which implements the logic from glibc.
2) Remove syscall.Set{res,re,}{u,g}id. Anyone that wants that behaviour can use syscall.Syscall6 and syscall.SYS_SETUID or whatever. At least, they could add some really loud godoc to those methods.
The main problem with that is that `os` tries to have a cross-platform API, and (for example) BSD has no saved user or group IDs and therefore no setres{u,g}id. I suspect Windows and Plan9 are even weirder.
I like a lot of things about Go, but I wish they didn't invent their own mini operating system in the runtime on top of Linux/POSIX. This bug seems like a good example of why that's a leaky abstraction.
I think it would be interesting to explore a coroutines + threads + channels design space for a concurrent language. Basically like Go, except without the green thread implementation.
For CPU bound work, you can use threads. For I/O bound work, use coroutines. And then they all compose together with channels. The implementation would be a lot simpler because it works with the OS rather than trying to paper over it.
You might be interested in Smallest Federated Wiki[0][1], a software project by Ward Cunningham (creator of the first wiki). It focuses more on collaborative, distributed editing than distributing content though.
(Some might find the documentation for the `guix challenge` command interesting: https://www.gnu.org/software/guix/manual/html_node/Invoking-...)
[0] https://www.gnu.org/software/guix/ [1] https://nixos.org/nix/