Diseased Open Source Software Community - it's about ethics in Code of Conducts

  • Thunk-Provoking
Reactions: Gorton Colu
Ffmpeg is probably the best FOSS project ever.
It is, at the very least, one of the most used and most useful, really only falling behind GNU/Linux... although if GNU/Linux weren't a thing, we'd probably still have a lot more Unix boxes in production environments (or even modern OS/2 successors, especially if Microshit decided to prop OS/2 up instead of Mac to avoid becoming a monopoly)
 
I mean specifically how they're going to make it runnable in ffmpeg
No need to inform me, I have a large-v2 right here on this machine
But how do they want to make it run across so many platforms? Use a teeny tiny model?
+It runs automatic speech recognition using the OpenAI's Whisper model.
+
+It requires the whisper.cpp library (https://github.com/ggml-org/whisper.cpp)
+as a prerequisite. After installing the library it can be enabled using:
+@code{./configure --enable-whisper}.
+
+The filter has following options:
+
+@table @option
+@item model
+The file path of the downloaded whisper.cpp model (mandatory).

+
+@item language
+The language to use for transcription ('auto' for auto-detect).
+Default value: @code{"auto"}
+
+@item queue
+The maximum size that will be queued into the filter before processing the audio
+with whisper. Using a small value the audio stream will be processed more often,
+but the transcription quality will be lower and the required processing power
+will be higher. Using a large value (e.g. 10-20s) will produce more accurate
+results using less CPU (as using the whisper-cli tool), but the transcription
+latency will be higher, thus not useful to process real-time streams.
+Consider using the vad_model option associated with a large queue value.
+Default value: @code{"3"}
Maybe they aren't including the model yet (or ever) and it's Bring Your Own Model. But if you use one that's too large it could be too slow for real-time transcription.
 
And my 54 yo friend cant obfuscate a rootkit inside... dont make me laugh please... nobody is checking open shource (FOS) trash they js blindly trust
If there was something as deep as a rootkit, it would be hard to hide and likely any attempts to put such in would have been found by now. I don't think there's ever been any cases of a rootkit being in an open source project and not being detected.
Didn't heart bleed show that just because a project is open source it doesn't mean someone has looked over it?
People have looked over it, but that doesn't mean it's free of security vulnerabilities (Heartbleed) or even intentional backdoors (xz). But I feel like a rootkit would be especially tough to hide from people looking at the code.
 
what's with all the schizoposting in this thread lately?
Screenshot_20250726-191911.webp

It's right there
 
a rootkit would be especially tough to hide from people looking at the code.
- 2013 to 2021, arbitrary code execution on pretty much anything running a Java server. 93% of enterprise clouds affected.

- 1989 to 2014, arbitrary code execution on web servers using CGI scripts (most of the ones from the 90s and early 00s)

And these are just the ones we know about. See Stuxnet for what a professional organization could do way back in 2010, and extrapolate from there.
 
  • Like
Reactions: HootersMcBoobies
If there was something as deep as a rootkit, it would be hard to hide and likely any attempts to put such in would have been found by now. I don't think there's ever been any cases of a rootkit being in an open source project and not being detected.
One factor you’re forgetting is that the folks who know about exceptionally long-lived backdoors in software don’t want to reveal them, because 1) they are useful and 2) the longer they sit undetected, the funnier the situation becomes.

Also, LOL
 
Back