@kuali said in Fired? But I Maintain All the Software! Vol. 3 Discussion!:
So to be clear, what I think happened in this part is that she started with a server does everything (even graphical rendering) approach, and shifted to the server sends updates, each Smart Frame renders the results itself model once she lost most of the servers. (I don't think she could have gone fully peer-to-peer, since she still needed to stream the rest of the performance from the remaining server. And each frame having to transmit to each of its peers would have had some 'interesting' effects on network performance. But it's hard to tell with this series.)
If that's what happened, then I agree with you that the first approach was very stupid. Even if the server did the composition there was no need to do the entire rendering and stream a video - just send the composed state to the frames that take care of rendering it.
With 40k people in a small area is already difficult to get a good network, no need to fill up the bandwidth for no reason.
But at the end we're trying to make technical sense of something the author just wrote as a whim because it looked cool.
@kuali said in Fired? But I Maintain All the Software! Vol. 3 Discussion!:
I've no idea how good Erlang would be for something this graphics heavy, but, maybe? That said, regular Android apps (and VR games, as of the last time I used my Quest 2) generally can't update while they're running.
Nope, but a new app can be installed and the controller/server could tell the devices to run app Y instead of app X. It all depends on how you design the platform.
It's actually a good design for smart frames for events, you register them with a controller for an event and the controller tells them what to run, dynamically, without the need of flashing a new firmware every time. Then you reuse for other things.