I’ve also not had great luck with MOTU devices (624, 8pre-es). Granted AFAIK, they’re still not supported in mainline kernel, but I found a few kernel modules on github. Those kernel modules work in that the audio interfaces are detected and I can play audio, but after a couple mins (sometimes immediately), it sounds like I’m getting buffer under runs even if I max out my buffers. If I disconnect and reconnect the devices it will sometimes work for another few mins. They work perfectly on windows. My preferred DAW is also windows only, but I can run a windows VM and do USB pass through on the either of the audio interfaces (other is connected via AVB), and it works great. So this is how I do audio, but this also means I’m using onboard audio for everything except the windows VM.

1. Why not both? Packaging multiple releases, documenting, and support is lessened with a single release. Officially supporting more ways to install is extra time and effort that is considerably worse with PHP than applications written in most (maybe all?) other popular languages due to the variety of ways people can configure PHP and how the web server executes it is huge and trying to support all of that is considerable. Even if you just narrow down to a single http server, there’s a lot of variations just how the http server executes the scripts and that’s ignoring the PHP/PHP extension level differences. I can’t think of any popular languages that are worse or even in the same ballpark as PHP on execution environment inconsistencies.

2. The existence of the docker release doesn’t prevent you from running it outside of docker and the Dockerfile/image serves as a reference implementation. It provides you the exact steps and working configuration to deploy it outside of docker.

Consider a PHP application with install instructions, you follow them and it doesn’t work due to some non obvious configuration difference. With the docker image you have a reference of what should work and can use that to narrow down what is different between your PHP install/configuration and a working system.

If you’ve not run in to these kinds of situations, consider yourself lucky. It was a nightmare back in early 7.x releases and older.

Years ago I’d have one PHP app that required version X of PHP and another that required version Y and my distro often only had one of them (or you couldn’t install both simultaneously), so I’d have to either compile myself (or later use a 3rd party repo). All solvable of course, but then throw in MySQL version requirements and PHP extensions and it’s just extra crap that containers just take care of for you. I’ve had this kind of inter app requirements conflicts with stuff other than PHP, but I’ve had by far more of it with PHP. For a while I used FreeBSD jails to help, but jails was kind of a pain. I enthusiastically embraced docker for PHP stuff early on.

A benefit for application developers, particularly PHP is there’s a lot of differences between distros and how people install and configure PHP. Even like which PHP extensions are available and their settings. Other languages things tend to be more consistent at the system level and customizations are app are usually application level (contrast with PHP extensions and system level configurations). It really helps reduce support issues due to distro/user differences if a developer just provides a working dockerfile as a reference implementation and in my experience this is far more likely with PHP than other languages. I realize this is mostly applicable outside of PHP, but I actually personally see more benefit with PHP based on my past experiences.