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

  • Thunk-Provoking
Reactions: Gorton Colu and The Mass Shooter Ron Soye
Dante Alighieri said:
Ffmpeg is probably the best FOSS project ever.
Click to expand...
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)
 
XL xQgg?QcQCaTYDMjqoDnYpG said:
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?
Click to expand...
+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"}
Click to expand...
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.
 
  • Thunk-Provoking
Reactions: 306h4Ge5eJUJ and XL xQgg?QcQCaTYDMjqoDnYpG
THE URANUS SPOTTER said:
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
Click to expand...
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.
Betonhaus said:
Didn't heart bleed show that just because a project is open source it doesn't mean someone has looked over it?
Click to expand...
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.
 
  • Like
  • Dumb
Reactions: Samuel Fuller, RGBCube, woowie queen and 2 others
AmpleApricots said:
what's with all the schizoposting in this thread lately?
Click to expand...
Screenshot_20250726-191911.webp

It's right there
 
  • Feels
  • DRINK!
  • Like
Reactions: RGBCube, woowie queen, JustSomeDong and 6 others
Markass the Worst said:
a rootkit would be especially tough to hide from people looking at the code.
Click to expand...
- 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
  • Winner
Reactions: fuckingIncredable, Samuel Fuller and HootersMcBoobies
Markass the Worst said:
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.
Click to expand...
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
 
  • Agree
Reactions: Samuel Fuller
2 Girls 1 Jar said:
- 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)
Click to expand...
Those aren't rootkits. At most they would be considered backdoors (if they were intentionally inserted).
2 Girls 1 Jar said:
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.
Click to expand...
Stuxnet did not involve inserting malicious code into open source programs, so I'm not sure what relevance it has here. Professional organizations have impressive capabilities, sure, but if we are assuming they have abilities we have no evidence for and can't mitigate then we're fucked anyways.
Pluciferous said:
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
Click to expand...
I doubt that. The backdoors are a risk to them too if they use the software. It's good practice for maintainers to use their own software anyway ("dogfooding").
 
  • Agree
  • Like
  • Dumb
Reactions: Samuel Fuller, RGBCube, 306h4Ge5eJUJ and 4 others
You must log in or register to reply here.
Back