补充一下上面的评论。

LBE 是第一个提出主动防御概念的，当年也是红极一时。

刚才搜了一下，LBE 安全大师大概 2013 年左右提出 [1]，利用最广泛的应该是当年的签名漏洞 MasterKey [2]：Android 系统对 .apk 包内同名的文件，只会校验第一个文件的签名，因此可以对系统应用创建第二个 classes.dex 来绕过签名检测、获得系统签名权限，360 极客版应该也利用了类似的漏洞。接下来要做的事就很简单了，Hook 不同 API 在原生层面是很容易实现的事。

360 极客版 14 年推出、17 年停更 [3]，LBE 安全大师 19 年停更 [4]，现在 LBE 唯一运营的产品应该就是 LBE 平行空间了。

360 极客版另一个学习的应该是 oasisfeng （即「绿色守护」开发者）的休眠机制，可以说是集众家之长的成果。今天，这些功能都已集成进 Android API 或国产 ROM 底层了，极客版们自然就不复存在。现在是 Magisk/KernelSU 、Xposed 的时代。


[1] https://sspai.com/post/19595
[2] https://nvd.nist.gov/vuln/detail/CVE-2013-4787
[3] https://bbs.360.cn/thread-15205527-1-1.html
[4] https://www.lbesec.com/#/products/2

@sickoo #5 光猫开了 WiFi 功能吗？有没有人在偷 WiFi 上网？

看看路由器占用？截图光猫速度有啥用啊

Electron App 的又一优美设计。

你再看看，是不是每个有自动升级功能的 Electron 软件都在这么塞，还要再塞一份完整版的最新安装包

有没有可能，操作系统本来就会利用空闲内存做缓存。你现在感受到的已经是缓存充分优化后的计算机速度了

MPI 是消息传递机制，Multithreading 是共享内存机制。在 SMP 的前提下，一般来说共享内存性能要高于前者。单台 PC 是 SMP 。

差评，非常不符合我对 Tkinter 的刻板印象

star 了

为什么不可以？

https://wiki.greasespot.net/GM.xmlHttpRequest

NAT4 无法穿透的本质是 Address&Port-Dependent Filtering ，猜测 NAT4 端口目前通用的策略就两种，假设规律（比如递增或者别的什么规律）和生日攻击。

生日攻击的实现可以参考 https://github.com/jflyup/nat_traversal 。不过实际中运营商不会允许同一 IP 同时占用那么多表项，所以成功率很低。

之前论坛里也有说 Frp 的 XTCP 模式会尝试猜测 nat4 端口，可以看看他们的算法： https://www.v2ex.com/t/995966 。

不过我从家宽连接教育网里的服务器（两边 NAT4 ），从来没成功过…

@james122333 #150

> ram 占用也是一样的 systemd 主进程不算 还有很多子进程 要一并算在内

我看了一下我的桌面端占用：一个 systemd 10MB ，一个 systemd user 进程 8.4MB 。还有什么「起服务调度作用」的「子进程」？

另外注意比较公平：如果你认为 systemd-journald 、oomd 、resolved 等 systemd 模块也算 systemd 的一部分，那么请在计算 OpenRC 的占用时，把对应的进程也加上。毕竟 systemd 系统上是不需要那些进程的。

---

> 还脑测程序性能 ... 我要额外装 systemd 再给你看证据？

而我确实是有安装了 OpenRC 和 systemd 的服务器的，systemd 还是装在树莓派上的那个。需要我贴图给你比较两边的占用吗？我的结论是：两边占用差距不大，甚至 systemd 这边更小。

---

> systemd 除了违背哲学以外还有 bug 以及漏洞问题

？？你推崇的 Shell 没有 bug 和漏洞问题？

---

> 只有在这环境打滚久的会觉得 systemd 是垃圾
> 根据使用经验 效能也体验不出来的

比资历和经验就没意思了，那你说得都对。

---

> 但写的差的你也没讲

systemd 是你说的「写的差」的吗？

---

> 讲这种话我是觉得你应该不是开发 C

我还真是写过 C 的，而且主要就是嵌入式。另外「我写没写过 C 、有几年经验」和我的回复对不对有什么关系？

还是那句话，程序员用数据说话。不贴数据猛贴资历，那我没话说了，你说的都对。

---

> 至于 systemd timer 我看来还不如 cron

说了半天终于回主题上了，然而也没给任何证据，就一句「 xx 不如 yy 」。同上，不知道你想说什么。

提供一个 Systemd timer 的解法，在 /etc/systemd/system 下分别新建 myscript.service 和 myscript.timer 两个文件，填写以下内容：

myscript.service：

[Service]
Type=simple
ExecStart=/path/to/myscript.sh

myscript.timer：

[Timer]
Unit=myscript.service
OnUnitActiveSec=7m

[Install]
WantedBy=timers.target

然后 sudo systemctl daemon-reload && sudo systemctl enable --now myscript.timer 。结束。

以上内容手敲，不保证对。

@james122333 #147

> 早就破 30MB 了好吗 压缩的不是真实大小……openrc... 2MB 以内 算上额外脚本包也多不了多少

我认为你和我说的根本不是一件事：我说的是 RAM 占用，你说的是安装后的文件体积。

---

> systemd 要做那么多事早就注定它小不了 运行的东西多怎能期待它能占用小
> C 语言上限高不代表用 C 写的都是好货

「注定它小不了」的数字和证据，来源请求？请勿脑测程序性能。我用你后一句的原话返还：要做的事情多不代表占用大、组合性好不代表占用小。

---

> unix 哲学好在我能够用原生工具凑出我要的东西 而不用上游没出下游不用想

是的，Systemd 和 Unix 哲学有冲突，但正如我说的，很多人不喜欢 Systemd 就是因为它的设计。KISS 和 All in one 本来就是有分歧的。但在服务调度和管理这件事上，我站 systemd 这边。

我没有一棒子打死 Shell ，只是认为应该给 systemd 正名。毕竟「污名化」「虚无化」 systemd 的声音太多，会给 Linux 萌新错误的第一印象。

---

> 你太小看脚本了

我哪里说脚本不好了？我的原话是：「就楼主这个需求，systemd timer 应该是最简单、轻量的解决方案」。你说的和我的回复有关系？

---

> 再给你个看法 一个东西能性能高占用小 语言只是其中一个因素 很多时后更重要的还是在于你怎么写

你也知道只是个「看法」了，那我没啥好说的。就 C 和 Shell 的性能问题，我相信你心里有杆秤：你要硬说 Shell 就是能在服务管理的性能、功能和占用上替代 C ，我也没办法。我只知道嵌入式 Linux 很多都开始回归 systemd 了，我的印象里，16MB RAM 的板上系统跑裁剪版的 systemd 没有压力。

@mingwiki 必须纠正一个误区：systemd 可能确实看起来功能很多，但毕竟是用 C 写的，实际上是非常轻量的：本身完全体只占用不到 10MB 内存、CPU 占用接近 0 。OpenRC 之类靠 Shell 程序的解决方案，怎么做都不如 C 性能高、占用小、功耗低。如果只看占用和功能，实际上服务和需求多起来，OpenRC 占不到多少便宜，对服务的控制力度还小得多。

大部分人还是由于对 systemd 的学习曲线望而却步或者不认同 systemd 的设计，所以认为 systemd 臃肿。但就楼主这个需求，systemd timer 应该是最简单、轻量的解决方案。

问问题建议说清楚：

什么叫“线下操作”？我理解的线下有七八种不同的意思。

“这样是否能用 java 实现”：“这样”是哪样？

什么叫“操作”？用户在 windows 资源管理器中操作还是你的代码操作？

实在说不明白话就举例子吧。

Does this have anything to do with https://github.com/2noise/ChatTTS/ , a Chinese/English text-to-speech model, which recently gains popularity due to its high fidelity?

#1 同问，感觉没听过医生这么说话的。

要不换家医院吧，我之前去市医院买药都是和外面一个价，处方药还更便宜