Not really, just do a rolling deployment like you should be doing anyway. No one cares if the new version takes 1 millisecond to start up or 3 seconds because they literally won't notice.
If your Java app takes half a minute to initialise it's the app's problem, not Java. Modern Java frameworks have moved from a dynamic deployment model to statically compiled and can start in milliseconds.
(for example, see the benchmarks on https://quarkus.io/blog/runtime-performance/)
Hardly, it's a fantastic guardrail when combined with health checks. You can say "you don't need it", but everyone makes mistakes sometimes. Make those mistakes not matter. You also take backups, right? Same idea.
It has a non-zero cost though, which is why I don't like it.
Things go wrong with the "roll" for example.
You have potentially two versions of your code running against the same DB for some time.
Stop -> deploy code -> start is simpler and less likely to go wrong.
I guarantee they focus-tested it and found that most people who remember Clippy don't have fond memories of him (and/or remember the memes/jokes about him more than they remember the actual Clippy), but, more importantly, most people don't remember him at all and wondered why this weird paper clip guy was talking. he hasn't been in an Office product since, what, 23 years ago or something? (not counting cameos)
The whole VPS can go up in smoke fairly easily too, quite literally in some cases. There were a couple of small VPS providers hit buy the fire that took out one of OVH's data centres and either had no backups or had the backups on other machines in the same building. Heck, many cheap VPS providers don't have a reliable backup system at all, some are honest about it (and tell users to manage their own backups) and some are less so. Also remember that a small VPS provider will have low staff because the margins are low, so if there is any manual intervention needed to restore services when there is a hardware failure you might find spinning up a new VPS elsewhere, restoring your own backups¹, and switching over DNS, is faster than the hosting providers restore process. And their backups are often daily, with your own you may be able to efficiently manage much more frequent (hourly, or even perhaps near real-time if your apps are not write-intensive) snapshots. You aren't going to get a 1-hour max restore and 1-hour max data-loss guarantee for $4/month!
Keep backups in any case. Preferably on another provider or at least in a different physical location. And, of course, test them.
And if you are managing a good backup regime, and monitoring your data/app anyway, is monitoring drives a significant extra hardship?
--
[1] in fact if you automate the restore process to another location, which I do for a couple of my bits, then you can just hit that button and update DNS when complete, and maybe allocate a bit more RAM+cores (my test mirrors are smaller than the live VMs as they don't need to serve real use patterns).
When you dig deeper, you will indeed find that the public reason for these kind of restrictions is "to keep the user safe".
They claim to be worried about malware installing their own extensions, so they lock everything down. As if that same malware wouldn't just patch the firefox binary to allow loading unsigned extensions.
It's ridiculous and obviously meant as a first step towards a walled garden. It's very unfortunate that firefox followed google in this.
> It's ridiculous and obviously meant as a first step towards a walled garden. It's very unfortunate that firefox followed google in this.
Check out Firefox for Android. It has a Walled Garden of extensions. There is a list of about 20 whitelisted extensions. All others are (falsely) claimed to be "incompatible".
