NoiseTorch, a popular real-time microphone noise suppression app recently had a possible security issue but it's been reviewed thoroughly and it's back.
"NoiseTorch is an easy to use open source application for Linux with PulseAudio or PipeWire. It creates a virtual microphone that suppresses noise, in any application. Use whichever conferencing or VOIP application you like and simply select the NoiseTorch Virtual Microphone as input to torch the sound of your mechanical keyboard, computer fans, trains and the likes."
In the new version 0.12.0 they completed a review of the code, and no issue was found. To help against any future issues, they're no longer using a separate update server and instead they will be using GitHub releases so it's all more transparent. For added security, they're also now using more GitHub features to validate the code too.
On top of that the new release also has some code cleanups, and the actual filtering status will be clearer now so it should give a better user experience.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: Nic264That doesn't mean distros should keep the same name, after all it's not the same software anymore but a derivative, even if it's only small patches.
Let me give you some perspective here: there's literally barely any package at all in any distribution that doesn't have a single patch applied. Name me any program, I'll tell you that it'll have a dozen patches applied on Debian or Gentoo.
There's multiple reasons for that, all of which I have personally seen:
- Upstream might be dead, but the program still has a large user base
- A security patch needs to be applied STAT
- The distribution has a different or novel strategy to handle multiarch, so libraries need to be installed somewhere different
- The build files install support files wrongly and doesn't care
- The project fails to compile with a certain compiler version. Very common on Gentoo
- The project never considered you might want to install different versions at the same time
- The project doesn't work correctly with a certain library version
- The project doesn't work correctly with a certain combination of libraries
Some of those you'd want to push upstream, but it might take a while until they react. Some of those you don't, like when your distribution handles things differently.
If all of these would mean you'd need to rename the package, no distribution at all would have a Firefox, GNOME, KDE, LibreOffice, etc. None of the names you'd expect on a system would exist.
9 Likes, Who?
Quoting: DrMcCoyQuoting: Nic264That doesn't mean distros should keep the same name, after all it's not the same software anymore but a derivative, even if it's only small patches.
Let me give you some perspective here: there's literally barely any package at all in any distribution that doesn't have a single patch applied. Name me any program, I'll tell you that it'll have a dozen patches applied on Debian or Gentoo.
There's multiple reasons for that, all of which I have personally seen:
- Upstream might be dead, but the program still has a large user base
- A security patch needs to be applied STAT
- The distribution has a different or novel strategy to handle multiarch, so libraries need to be installed somewhere different
- The build files install support files wrongly and doesn't care
- The project fails to compile with a certain compiler version. Very common on Gentoo
- The project never considered you might want to install different versions at the same time
- The project doesn't work correctly with a certain library version
- The project doesn't work correctly with a certain combination of libraries
Some of those you'd want to push upstream, but it might take a while until they react. Some of those you don't, like when your distribution handles things differently.
I'm not arguing about the usefulness of distro-specific patches, I know they are often required to get the software to build, run or be well-integrated with the rest of the system.
All I'm saying is if the authors ask for something like changing the name for modified version, 3rdparty packagers should just respect those wishes. All it takes is just another distro-specific patch after all (half-sarcasm).
Quoting: DrMcCoyIf all of these would mean you'd need to rename the package, no distribution at all would have a Firefox, GNOME, KDE, LibreOffice, etc. None of the names you'd expect on a system would exist.
Hey Firefox was my example first! It requires an explicit written permission from Mozilla to keep the name Firefox in patched 3rd-party packages. Again, see “Fennec F-Droid” in F-Droid. It was also rebranded as IceWeasel in Debian between 2006 and 2017.
Let's also not forget about Google Chrome/Chromium, Visual Studio Code/VSCodium/“Code - OSS” and others.
I'm not saying that's the kind of thing I want as a user, but it makes sense to me that original name = software that's officially endorsed and supported by the authors.
The relationship between developers and packagers is often complicated… So I'll leave you with this example from KDE where the author of Okteta opposes a Microsoft Store publication, and his wish is actually respected by the packagers! 🤯
0 Likes
Quoting: Nic264It was also rebranded as IceWeasel in Debian between 2006 and 2017.And remember how much of a kerfuffle that caused. But even so, from what Dr. McCoy is saying I suspect there are many more lightly patched versions of Firefox where the patches are sufficiently small that nobody ever commented. But if you had a hard and fast rule, where any patch = rename, you would instead have had three dozen different Firefoxes.
0 Likes
You should try https://github.com/Rikorose/DeepFilterNet as amazing RTXVoice like quality
0 Likes
Patreon
PayPal
See more from me