分类 Linux 下的文章

我正在使用机械革命的设备,有得必有失,便宜的价格意味着某些硬件性能的阉割————比如糟糕的麦克风拾音效果。这主要是因为散热风扇的巨大底噪导致的。

好在,要解决这个问题理论上还不算太困难,语音降噪技术已经相当成熟,我们有许多降噪方案可以选择。
这次我打算试试NoiseTorch这个项目,如果部署体验一段时间后效果不错,我将会在Linux用户站同步更新部署方案。

尝试部署

从Github下载最新的二进制预编译程序,截至目前是v0.12.2
压缩包的结构如下:
2025-05-10T13:11:04.png
在压缩包所在目录执行:
tar -C $HOME -h -xzf NoiseTorch_x64_v0.12.2.tgz
此时desktop等文件应该已经位于正确的位置了,接着刷新桌面环境缓存使其正常显示在应用列表。
对于KDE用户:

kbuildsycoca5 --noincremental  # KDE5

kbuildsycoca6 --noincremental  # KDE6

对于Gnome用户:

gtk-update-icon-cache

在菜单搜索noise即可找到:
2025-05-10T13:39:40.png
你可能会看到如下窗口:
2025-05-10T13:42:04.png

窗口提示你 NoiseTorch 当前无法正常运行,因为它需要 CAP_SYS_RESOURCE 权限(一种 Linux 系统的高级权限)。如果你不了解此权限,可以点击下方的 “Grant capability (requires root)” 按钮,程序会尝试自动获取权限(需要输入 root 密码)。
如果你没有使用常见的桌面环境,可以手动执行命令授权:
sudo setcap cap_sys_resource+ep /home/$USER/.local/bin/noisetorch
如果你通过点击完成了授权,程序将在授权后自动重启,你会看到类似下图的窗口:
2025-05-10T13:59:46.png
默认开启了对麦克风的噪音过滤,你需要选择正确的PC麦克风设备(我的是Family 17h/19h/lah HD Audio Controller)并点击Load NoiseTorch
接下来,你会发现音频管理器里 多了一个输入设备:
NoiseTorch Microphone for Family 17h/19h/lah HD Audio Controller
随后,你可以在需要麦克风的设备中选择使用该设备即可实现麦克风降噪输入。
2025-05-10T14:05:02.png

效果体验:

坦白来说,效果不太理想。但是...这貌似不是因为软件导致的,因为我的麦克风真的是太烂了,我感觉他明显受到了某些电磁/震动干扰。或者说,我买回来的时候这玩意压根就是损坏的状态。
通过Audacity录音测试,我感觉是从完全不可用的状态到了很炸但是能听见人声的状态。
具体效果有待上游戏验证。录音太炸裂就不放了。
其实,就算用不了我也可以用MT6 Pro的麦克风,而且这个自带ENC降噪

关于翻译和打包问题

根据internalisation i18n,尽管项目目前还没有正式的支持多语言,但是显然社区都很乐意提供翻译支持,后续我可能会尝试fork 并提交第一个简体中文版本。
其次是有必要的话直接对项目进行打包生成便于安装部署的deb/rpm软件包。

你是否正在使用沉浸式翻译?或者划词翻译
前者可以通过开发者模式直接填写使用Deeplx ,而后者则不能直接兼容Deeplx API,需要根据划词翻译的自定义API格式对请求作转换处理,我们这里就使用到了Hcfy-Deepl Translation Adapter完成这一处理过程。

本文的免费原理:Claw Cloud 为注册用户免费提供5美元免费额度,其中Github账户注册时长180天以上的用户还可以每月免费获得5美元免费额度,因此我们可以利用免费额度运行一些资源占用较低的服务,比如:Deeplx及Hcfy-Deepl Translation Adapter

- 阅读剩余部分 -

评论区的广告骚扰涉及毒品广告,包括Github仓库和最终指向暗网的洋葱域名链接,URL是一个.ru域名,评论发送IP:149.50.116.160。

恶意攻击方面,比如:XSS试探攻击。
其中,一个IP为:38.147.191.215 来自Cogent的HK机房IP
评论内容为 http://xxxxxx/">alert(1)<a/href="#",其核心目的是通过闭合HTML标签注入JavaScript代码。
不过显然这种低级的漏洞试探对Typecho 1.2.1完全无效。

昨天凌晨准备更新文章的时候意外发现Linux用户站后台无法正常登录,点击登录后直接跳转到了主页面。
受限于时间原因,修复工作到了当天晚上下班。
开机后再次在PC上复现BUG 我的第一反应就是反向代理出现了问题,果不其然在网上找到了不少使用CDN后出问题的例子。
Github也有人提出了相关问题,最终解决方案:经过反向代理后,系统没有识别https

sudo nano config.inc.php
添加:

//  set ssl
define('__TYPECHO_SECURE__', true);

书接上回,为了便于使用公网服务器反代内网服务实现内网穿透,我部署了WireGruad,但是连接稳定性无法保证,连接总会在大约一天后断开。因此我想到了之前使用过的内网穿透项目:NPS和Frp,考虑到前者已经失去维护,并且后者的文档也逐渐健全,最终我选择了Frp。

参考文献

获取用户真实 IP —— gofrp.org
Accepting the PROXY Protocol —— Nginx docs

- 阅读剩余部分 -

我,人在西安,它,宕在郑州。
人已麻。
没事别动/etc/fstab ,有事也别tm动。
预计下次回家才能修,那就已经是清明节了,啊啊啊啊啊啊。

2025年4月5日更新

经过清明节至今天凌晨的抢修已彻底恢复 nas.xfox.fun和LinuxUse.site的反代。
同时,今后Frp将仅用作防失联的措施之一,不作为任何服务的主要对外访问渠道。
上述所有站永久切入HK三网优化线路,不再使用第三方反代业务。

顺带一提,修复排查的时候用了DeepSeek R1 和V3 但是发现回答会受到输入的错误配置文件的干扰使其产生幻觉。
所以我建议如果你想偷懒,最好让AI重新写配置文件而不是输入可能存在问题的配置信息让他修改。

购买新的服务器后,我也不打算继续续费sakurafrp了,所以反代提供公网IPv4访问的工作需要转移到Claw HK机上,同样地Mumble服务器的IPv4转发也需要迁移到Claw HK机器上。
除了博客本身直接部署,所有需要反代,转发的服务都通过WireGuard组网后虚拟局域网转发完成。

Nginx反代配置

nas.xfox.fun

- 阅读剩余部分 -

应用选型:Mailu

Mailu项目仓库

架构规划

主要设备

服务器名称硬件网络用途
境内Server BEliteDesk800G3 SSF ,G4600,2*8GB RAM无公网IP运行mailu 容器
境外Server ARackNerd VPS,1*Vcpu,768MB RAM有公网IP提供公网IPv4 地址

网络规划

考虑到方案1可能违反SakuraFrp的用户协议,暂定方案2。

方案实施风险
方案1在B上运行FRP客户端,开出公网端口用于与B的通信;在A上运行socat转发必要端口到A,实现A-B双向通信。依赖第三方服务(如FRP)的稳定性,可能存在性能瓶颈或配置复杂性。
方案2在A、B上运行WireGuard,实现10.10.0.0/24虚拟组网。配置较为复杂,涉及跨境组网,网络波动可能导致通信失败。

- 阅读剩余部分 -