@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 方法调用即可。

之前在其他论坛接触到过楼主，所以不用猜测是不是 AI 生成或者故意学翻译腔了，我可以辅证楼主确实普通话不熟练。

1. 不好说。是否省电取决的因素太多了，理论来说 Linux 的续航会好（后台没有什么闲置无用进程），实际上会差（硬件厂家对 Windows 有特殊调校、给 Windows 开放了定制的电源管理接口等等）；
2. 哪个发行版续航都差不多，当然你选 Arch 、Debian 一类的瘦发行版，自己从头开始装桌面环境，可能会好一点；
3. LXDE 、xfce 都还可以，当然最省电的还是直接用窗口管理器（ Window Manager ，例如 i3wm 等等）。我目前是 KDE 用户，实际体验续航也差不到哪里去。

@verrickt #79

事实上关闭 swap 也不能完全防止 thrashing 问题。就像前面说的，swap 的目的是「让匿名页面和文件后备页面具有同等的交换地位，都能够在内存不足时释放」。

即使禁用了 swap ，当内存高负荷时，系统也会尝试释放内存，只不过它只能释放文件后备页面（例如从磁盘载入内存的代码段、动态链接库、文件系统缓存等）：当文件存在脏写时，还是会触发大量写盘；当内存紧缺到即将读取的链接库和文件都要被释放时，还是会导致 thrashing 。

总之，我觉得楼主的问题还是在于内存不够。Swap 只是一种帮助缓解（也可能加剧） thrashing 的手段，但 16G 内存不能流畅跑需要 32G 的程序，这是任何软件都改变不了的。Swap 最多把「跑不起」变成「勉强跑起」罢了。

@luxor

楼上关于 Overcommit 的问题解释得很清楚了。我可以再总结一下：

1. 「关闭 pagefile 当然可以提高性能」：关闭 pagefile 和性能无关，只是影响你提交总量的多少；
2. 「某些应用对已提交内存占用的优化不够，造成实际物理内存占用不高」：正是因为应用会提交更多内存（有的是因为沿袭了 Linux 的习惯，有的纯粹是在设计上难以解决），所以开启 pagefile 才是必须的。否则由于 Windows 的特性，你将连本来的物理内存都不能完全利用；
3. 「可以减少大量的磁盘读写，延长磁盘的寿命」：一方面，Windows 在交换方面已经很保守了；另一方面，如果出现「大量的磁盘读写」情况，说明平时的工作负载（注意！这里说的是实际的内存使用。仅仅提交很多内存而不使用，并不会产生任何磁盘读写。参考楼上）对内存来说已经不堪重负了，那么升级内存是最佳解决办法，而 pagefile 也能作为一种后备资源来在瞬时高负载时分担一下。关掉 pagefile 属于纯纯的掩耳盗铃、自欺欺人，其结果是工作负载运行不起来了。而且由于第 2 点，就连原本的物理内存都无法完全利用了，百害而无一利。