挺好的，已 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 库，写的时候也得注意兼容性问题。

此帖可能有帮助 https://meta.appinn.net/t/topic/31599

@yumizhao888 #23 您看懂我在说什么了吗？流汗

第一句话是一看也不看啊

你自己读读自己说的什么东西，前后关系大吗？一会 GPT 一会 pycharm 一会 C# 的，想问什么都没说清楚，语文水平有待提高

=========

什么都不说我只能帮你算一卦了：

您测试的英文名：yumizhao888

易理：忍得若难，必有后福，是成是败，惟靠紧毅

『数理』：沦落天崖的失意烦闷的数。（凶）

『签语』：（破兆） 家庭缘薄，孤独遭难，谋事不达，悲惨不测。

『含义』： 多破兆，家属缘溥。丧亲、丧子、兄弟姐妹分离孤独，不如意，烦闷，危难，遭厄，浮沉不定，为了慷慨。施惠招怨，劳而无功，凄惨孤独，其他好运者不多，有伤夭寿。

@msg7086 谢谢提醒。你是对的，我确实弄混了。

@yuzii 现代文件系统基本都是懒分配：写多少用多少，并不是你申请 1GB 空间，硬盘上就会少 1GB 空间。

所以还得再加个条件：远古的、不支持 prealloc 的文件系统。

https://w568w.github.io/rockchip-boot-process.html

想起以前写过一篇简析…

具体流程嘛那就不会了，也许里面提到的资料可以帮你

有些朋友对 Arm 的称呼感到迷惑。之前博客写过一篇 Arm 相关术语命名的文章，摘几段过来供参考：

====分割线====

1. 「 Arm 架构」是一组精简指令集架构（ RISC ）的统称（注意，是一组，不是一个）。

2. 英国公司「 Arm Limited 」是这个架构的设计公司。

3. 字母全大写的「 ARM 」在很久以前是对橡果 RISC 机器和高级 RISC 机器两家公司的架构的称呼，这些架构今天已经不再使用，如果你想避免歧义，请尽量称呼「 Arm 」。

4. 「 Armv9 」和「 Armv8 」等是指 Arm 公司发布的一个架构版本 。

5. 「 Armv9.4-A 」是 Armv9 的一个最新的扩展，相当于架构的打补丁版本。后面的 -A 是指一个子版本，-A 指这个架构是用于应用场景（ Application Profile ）的，比如手机、电脑，还有 -R 用于实时场景（ Real-time Profile ），例如无人驾驶和工业自动控制，-M 用于微控制器（ Micro-controller Profile ），例如树莓派。

6. 「 AArch64 」是 Arm 处理器的一种执行状态 （注意，不是指令集，也不是架构！不要再说「 aarch64 架构」了！），在这个状态下，可以使用 64 位的寄存器，这一状态在 Armv8 中首次引入（所以 Armv7 及以前都是 32 位架构）；相对应的，原先的 32 位状态被称为 AArch32 。同一个处理器可以通过设置一个专门的寄存器，在这两种状态之间切换，这就是为什么你可以在 64 位的系统上运行 32 位的程序。

7. 「 A64 」是 AArch64 状态下唯一的指令集 （注意，它才是指令集的名字）；相应地，「 A32 」现在用来指代早期的 32 位指令集；「 T32 」是 A32 的一个子集，它特指 Thumb2 指令集（指令 16 位和 32 位长混合）。

8. 「 arm64 」这个说法，Arm 公司从来没有在正式文件中提过，这似乎是苹果、微软和 Linux 喜欢使用的简便称呼。我个人把它理解成一种移植（ Port ），即一组指令集和架构的统称。

9 。 其他移植名还包括：armel 、armhf 、armv7hl 、armv7l 、armv8l 等。其中 armel 面向 armv4-v7 的 armeabi 接口，的兼容性最好（但性能可能最低）。再强调一次：这些名称不是标准，不同的发行版、公司、系统和项目都可能有不同的定义。例如，同一个架构，苹果设备上可能叫「 arm64 」，但在一些 Linux 中可能又叫「 aarch64 」了，非常混乱。如果你和别人交流移植相关的问题，务必明确你在说什么。目前比较通行的称呼一般来自 LLVM 和 Debian 。

提个建议：既然号码只需要你能看到，发个公钥不对称加密一下安全性更好。

每天 3 分钟，在家即可挖矿，无佣金/保证金/隐形收费

https://cuts.top/DUyC

@xuegy #26 Ansys 我简单看了一下官网文档，目前推荐的就：

- Red Hat Enterprise Linux 7.8, 7.9, 8.4, 8.5, 8.6, 8.7, and 8.8
- SUSE Enterprise Linux Server & Desktop 12 SP5; 15 SP2, SP3, and SP4
- CentOS 7.8 and 7.9
- Ubuntu 20.04 and 22.04
- Rocky Linux 9 (From 2024 R2)

Ubuntu 根据要求排除，CentOS 很快停止支持也排除，那剩下选择基本就是：

- RHEL
- SUSE Enterprise
- 等 2024 R2 支持，然后换 Rocky Linux 9
- Ubuntu 自己卸掉 snap 。退一万步说，不要听 v 站朋友说就见得风是得雨，snap 再烂也是目前唯一完全沙盒化的企业解决方案


---

顺便问问 PopOS 作为服务器系统有啥优点啊，看楼上好多人在推荐，我对这系统的印象还是「面向 PC 游戏玩家的发行版」这一类的。

是什么行业软件？方便的话列一下做参考。

@xjpicism

1. 这个是我听过 Go 开发者很多次的辩解。第一，这样的用例实在少，你在标准库以外恐怕都找不出几个；第二，即便有这样的情况，从类型论角度来说，也应该是 string 和 (string, error) 的和类型，而非 (string, error) 这单独一个积类型，从抽象上来说依然是缺陷的；
2. 既然 Go 的开发者会关注「同时有错误和返回值」的小众需求，怎么「作用域结束清理」这种非小众需求、甚至 GCC Extension 和 Clang BlockExtension 同时都实现的需求又不管了呢？
3. 我的意思正是 Go 错误地删掉了 Enum ；
4. Go 没有官方的、强制性的包结构规范，因此很多开发者会这么做，甚至你去 CSDN 之类的国内网站全是教你这么做，导致产生了大量低质量、不规范的包结构，pkg.go.dev 已经被污染得不能看了。至于人工审查，你能告诉我为什么 Pypi 、Crates 、Dart Pub 、Conan 、vcpkg 上都没有我提到的这种情况吗？
5. 省的那点资源已经被每次函数调用都检查一遍是否初始化给抵消了吧。

Go 的很多设计总是给我一种「能用就行」「就差一点」的感觉（不是攻击 Go 开发者，我知道人都是很牛的大佬）。以下是我最不满意的几个点：

1. 创新性地使用了「错误亦返回值」的概念，很先进吧？但错误和返回值的关系应该表示成一种和类型（ Sum Type ），即「 A 或 B 」，Go 偏偏设计成了积类型（ Prod Type ），即「 A 和 B 」。导致很多时候不得不写出 return "", err 这样的愚蠢代码。Rust 、Haskell 等都没有这个问题；
2. 引入了做 cleanup 的 defer ，相比 RAII 其实不优不劣。但 Go 偏偏限制 defer 只能作用于「函数作用域」，导致经常要写「 for 循环里套匿名函数」的丑陋操作；
3. 直接干掉了 Enum ，把命名空间展平。后果是所有 Enum 的名称都变得非常长；
4. 仓库即包。想法很美好，但偏偏没有一个人工审查的包仓库：每次要找某种功能的包，都要在 pkg.go.dev 无数个 0 star 的、作者本意根本不是通用库的业务逻辑和模块包里翻；
5. 结构体允许不完全初始化，又不允许赋默认值。标准库里有些之前没写 New 方法的结构体，为了保证兼容，都只能在每个结构体的函数前面插一句 ensureInited() 之类的调用来补全默认字段。

小新的国际版类似物是 IdeaPad 吧，可以看看：

https://github.com/Sino-Huang/ideapad2024-power-management

https://github.com/0xless/battmngr

https://wiki.archlinux.org/title/Lenovo_IdeaPad_5_15are05

看楼主应该是联想小新的。拯救者的话有社区维护了内核驱动：

https://github.com/johnfanv2/LenovoLegionLinux

小新就不清楚了，按楼上方法抓 ACPI 方法调用即可。