I really don't care about running *multiple* compilers. If the VL6 GCC works, and makes things that run on the boxes, then I'm perfectly happy using that.
Sometime back, I *tried* to just do a fresh compile of a newer GCC, because the stock 5.8 one had issues and bugs that prevented things like newer versions of mplayer and VLC from compiling. In that attempt, I ran into dependency hell that eventually ended up hosing the system libraries and bricked the test machine.
That's why I tried to just drop a later GCC in from VL6 to see if that would let FFB9 run. I expected total disaster, but was surprised that it seems to work.
I'm waiting for some shoe to drop, which is the reason for the initial questions. I'd like to find out *before* I commit changes to the master machine and end up with 40+ door stops.
You will invariably be running into a wall ... sooner or later. I suspect sooner.
Later would be nice. With tablets, smartphones, and the proliferation of laptops, coupled with hotels and other venues having WiFi access and more people using 3g mobile connections, the need for what we do is dwindling. However, people still find our service valuable, so I'm trying to stick it out while I can. I've been doing this now for 17 years, which goes back to dumb text terminals connected via dialup modem, so at least on one level, I'd not mourn the loss.
You need to either sandbox these machines or upgrade the distro or machines or both. Perhaps LTSP or some form of it
will help.
They're already sandboxed in a NAT isolated private network. And distro upgrade's pretty much been tried. The newer ones have just too much bloat, dependence on Gnome, massive numbers of extra daemons, etc. that they're just too slow on the hardware.
Using a terminal server model could help, perhaps, but there's 2 main issues:
1. The setup would have a single point of failure with the server. There's been a distinct advantage that every machine in our setup now is totally independent and self-sufficient. Because there's no sever/client or master/slave relationship, and every machine can perform every function (including becoming an Internet access router feed to the others), there's extreme redundancy and flexibility that would be lost if there had to be one or more servers being critical to the overall function.
2. I've not found any non-proprietary scheme that supports sending audio to the individual client machines. With the web becoming rife with video, flash, and other audio/video media, having just a terminal server without audio in our application would be pretty useless to most who use it. Also, since this is a multi-user setup, the audio couldn't just be a network routing of the server's sound card....it would have to be *each* user getting *their own* specific audio stream.
This would mean an audio server akin to the video's X server. If there is such an animal in the FOSS world, I'm unaware of it.
As for upgrading the machines, I'd *love* to do that. But the cost would be in the thousands at least for anything reasonably modern. The basic requirements are:
1. All in one design to minimize the setup time and space requirements.
2. Compact and rugged to allow packing 30+ at a time into a minivan for transport.
3. Rugged keyboards/mice that are easily replaced and cheap enough to not worry about damage.
4. Big enough and/or mechanically secureable to discourage theft. This also implies using laptops or something new and shiny is NOT a Good Idea.
5. Identical hardware for all machines so that OS cloning for updates is practical without worrying about individual hardware differences.
Along with all this is, as mentioned, the expected decline in need in light of the fact everyone's getting the Internet in their pocket.
