@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 同问，感觉没听过医生这么说话的。

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

一项目一环境的话 pdm 就挺好的，用起来很像 yarn 或者 npm 。

直接用 RunAs 不行吗

对 IPFS 一窍不通，比较好奇这种去中心化技术是如何保证网站存活的呢？种子对做种者来说有直接利用价值所以才有人心甘情愿做种，但会持续有人无偿、自愿地贡献电费和储存资源来维护你我的博客吗？

我认为 Copilot 就是一种自动补全。Excel 的补全手柄用过吧？输入「周一」「周二」之后，一拖就能帮你把「周三四五六日」补全的那个。

你用 Excel 时，会觉得这玩意儿废了你的打字能力吗？

别质疑自己，用好工具的能力也是能力。人的不可替代性在于聪明地思考、编写有逻辑的代码、出问题知道怎么解决，不在于输入代码的快慢。

@s642153378 一点进来就给我整笑了

这逻辑是一张一张头像请求 API ？感觉效率很低啊，好奇有什么逻辑是不方便写到脚本里而要远程部署的

你说的「互相影响」是什么意思？这不就几个目录，目录还能在开发时打架了？

SDK：Android SDK 本来就能多版本共存啊，build.gradle 里也要求指定 SDK 版本；

NDK：同上；

JDK：假设用的 Android Studio ，改一下项目级的 JDK 设置就行了。

1. 弃用（ Deprecated ）和移除（ Removed ）完全是两码事；
2. 框架内的归框架，这种需求应该框架定义注解，而不是直接套用类似语义（而且实际上不类似）的系统注解。

这开发者水平堪忧，不仅不懂英文、不懂 Java ，也不懂软件设计。

挺好的，已 star 。几个小建议：

1. 每个小工具要单独写一个 schema json ，其实不很人体工学（既指 schema 也指 json ）。有没有考虑让写脚本只需单文件？比如直接从 typescript 脚本里解析两个 interface 来确定输入输出结构和 Manifest 这些内容；

2. 和写脚本直接放到 ~/.local/bin 相比有什么优势？

我觉得脚本的意义就是用完即丢，不用考虑兼容性这些，随便硬编码也无所谓。但这个管理器看起来还能安装别人上传的脚本。说白了，越随意的需求越私人，没有发出去的必要；越公众的需求越正式，一般也不以「脚本」而是以「 API 」或「工具」相称，我写完了也不会发到你的仓库里。

我觉得不如转变思路，做个脚本的瑞士军刀 SDK ，把监控网页、显示 UI 输入、保存设置之类的常见需求都聚合起来，方便用户快速编写脚本，类似一个全平台的桌面端 autojs 。

补：Flutter 有 rust_bridge ，如果你一定想掺 Rust 进来，也不麻烦。

> 原生桌面框架 UI 样式不好写--不仅限于对齐、窗口自适应、flex 等等，各种绑定事件样板代码，写一个软件大部分时间都在写这些东西

可以试试 Flutter 或者楼上说的 Compose Multiplatform ，应该都独立于 Web 技术解决了这个阻碍。

> 串口通信等硬件交互，IO 密集、计算密集

Flutter 用的 Dart ，直接编译成原生代码，计算性能不会太差，但搞硬件交互可能要研究一下，估计要调第三方包； Kotlin 应该轻松一些。


> Tauri 对我胃口，就是不知道它现在怎么样了，还有那么多坑吗？

最大的问题是性能和兼容性差。我自己的不准确经验来看 Tauri 开发稍微大点的应用就会特别特别粘滞：冷启动慢、响应点击慢、拖动窗口慢、调整窗口大小卡，而且 Tauri 首次编译速度也慢得令人头秃（即便和 Electron 作比较，以上缺点也成立）；另外，因为一定要接系统的 Webview 库，写的时候也得注意兼容性问题。