I'd love a faster and more accurate option than Whisper, but streamers need something off-the-shelf they can install in their pipeline, like an OBS plugin which can just grab the audio from their OBS audio sources.

I see a couple obvious problems: this doesn't seem to support translation which is unfortunate, that's pretty key for this usecase. Also it only supports one language at a time, which is problematic with how streamers will frequently code-switch while talking to their chat in different languages or on Discord with their gameplay partners. Maybe such a plugin would be able to detect which language is spoken and route to one or the other model as needed?

Something we've been trying to solve for a long time is having instant DB resets between acceptance tests (in CI or locally) back to our known fixture state, but right now it takes decently long (like half a second to a couple seconds, I haven't benchmarked it in a while) and that's by far the slowest thing in our tests.

I just want fast snapshotted resets/rewinds to a known DB state, but I need to be using MariaDB since it's what we use in production, we can't switch DB tech at this stage of the project, even though Postgres' grass looks greener.

An HN thread is not the place to report a bug. Nor do I think it's fair to form opinions about project maintenance (which doesn't happen on HN) based on comments in HN.

Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).

> I believe that, but I also believe your attitude is a bigger threat to security than either.

I can't change your belief, nor do I care to, but I think that's absurd. Show me an actual security threat relating to this and I will address it. But this problem as stated is not one.

I know you've already made up your mind, but look at our track record of answering support questions on the forums and tickets on GitHub, and you'll see that the picture you've formed in your mind from this thread is not accurate.

Those comparisons are very straw-man and I won't entertain them. As I've already said, IMO there's more risk in introducing a new security bug in trying to fix this issue than there is leaving it as-is (failing fast and hard).