I frequently amaze new colleagues when I show them that deploying an update for our backend application is a sub-second affair. Our pipeline keeps track of what git tag was deployed last, diffs between that tag and the new release, and uploads the files to each of the deployment targets. It takes longer for the pipeline agent to spin up from Cold on a Monday morning, than it does to actually deploy.

The core of the application is just php scripts, and those are either immediately up to date whenever the next call is, or swapped out the next time that component finishes a processing cycle.

Docker containers are nice, but nothing beats the cause of a stack trace being fixed, tested and deployed to the acceptance environment within minutes of it arriving.

The original Test Drive Unlimited was great, but it rightfully bombed in reviews due to some really bad technical issues. Some of the car characteristics were really bad and off the mark, and the game suffered from an engine issue that was a problem other racing games had solved long ago;

On long slopes, the geometry of the road didn’t curve properly; the angle would have a polygonal jagging issue. This was most likely to shave off performance cost on the 360. Other games had already solved this issue by effectively smoothing angle changes, but TDU did not do anything of the sort. The result was that on hilly terrain cars would constantly bump around and lose traction due to weird unexpected air-time. Some cars were affected far worse than others, particularly super cars had a bad time.

I loved TDU, I loved cruising around in my Shelby Cobra and doing the one-hour tour around the island for decent money.

But the list of flaws is pretty long, and the technical issues made it a nonstarter for anything competitive.

I switched to using Moonlight to stream rather than Steam’s built-in RemotelyPlay months ago. It was just absolutely unusable; not a bandwidth issue, had that in spades. The problem was that it would either not connect, connect to a blank/green screen or the audio/video would randomly cut out. It would work maybe a fifth of the time, and if I had to reconnect for whatever reason, it would absolutely always fail.

Moonlight? It worked out of the gate, and has never failed despite running on some beefy encoding settings since I have very good WiFi with next to no interference from neighbors.

I desperately want Steam’s own offering to be better though. Not having to install a second tool, and to just connect from Steam directly would be a much more polished experience.

Tell me you’ve never used PHP without telling me you’ve never used PHP.

It’s known for giving a complete stack trace, it’s nearest neighbours and their god damn grandkids the moment it so much as coughs up a warning. For the longest time it was notorious for doing this as the default error logging level.

I’m aware it’s cool to hate on PHP, but it has plenty of things to dislike without straight-up inventing nonsense.

Everyone else is just telling you to do things in a way that is different, and while they are correct (you should use a unit.d/systems script for this depending on your distro), I’m going to actually answer your question since I know sometimes you just need a quick and simple way.

Depending on your version of cron, it may support special statements instead of the * * * * * notation for time.

The one you want is @reboot. Replace all entries of the schedule syntax with that, including the @, and the command will be executed only once when the system boots up.

Use that to start a script that checks for network connectivity on a loop with a sleep statement. Break the loop when you have connectivity, then execute your command, and exit the script.

Don’t ignore the correct way though. You’re better off executing this as a systemd (or equivalent) script. It’s barely more effort, and has the benefit of some nice built in logging and integrations.

I have some bad news…

My tried-and-tested method has saved my (company’s clients) ass a few times.

Every Mysql/MariaDB server has at least one replication target. This replicant is not used for access by the infra, and can be paused, restarted, etc with no issue and is configured with this in mind.

We run a mysqldump on the replicant. Depending on the resiliency required, we store the dump on the replicant and/or a third location.

The tools differ, but the practice applies to pretty much every database system and the database has the benefit of not being interrupted during the backup (replication is paused during the backup, and resumed after completion). This also has the benefit of already having replication configured, and adding a secondary redundant instance you can swap out for the master (or using the backup replicant in a pinch) means disaster recovery is much faster.

Also, I dislike many things about Azure’s offerings, but their Flexible Database for MySQL does the above for you as one nicely packaged solution for a reasonable-but-not-cheap price.