有些朋友对 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 点，就连原本的物理内存都无法完全利用了，百害而无一利。

稍微了解一下操作系统原理吧，避免几个误区：

1. 「已提交」和内存占用没有半毛钱关系，也不是程序「恶意偷内存」。哪怕你的已提交显示 1 TB ，物理内存只有 8 GB ，也完全不能代表你的电脑内存满了或者没满。「已提交」的唯一意义是告诉你「所有应用宣告申请了这么多内存」，但「申请」不等于「用」：很多使用自己的用户空间内存分配器的程序会直接从系统那里「申请」过来一大把内存（甚至比实际物理内存还大），然后慢慢用。真正的内存占用是指程序「用」的部分。这部分你应该通过 Resident Set 或 Working Set 来估算；
2. 虚拟内存是 Windows 滥用的错误术语之一。虚拟内存本身是操作系统的基本概念，指为每个进程都需要分配一个独立的地址空间，这个地址空间映射到物理内存页面中。你说的这项能关掉的功能应该是指交换空间 / 分页文件（ Swap ）。
2. 交换空间关掉并不能让系统在高负载下变快。相反，我不推荐在任何场景下关掉。它的目的是为了让匿名页面和文件后备页面具有同等的交换地位，都能够在内存不足时释放。关掉后，只有后者能释放，所以等于是在高负载下系统能强制释放内存的手段变少了一个，只会让系统更不稳定。

问题来了，有什么工具刷运营商的 CDN 流量吗

@masterclock

> 这个项目与 awesome-c 、搜索 有什么区别？

（ 1 ） awesome-c 并非记录了所有库；(2) awesome-c 没有给出任何有关库的详细信息，且其中 80% 的库都是属于「年久失修」的类型，搜索起来非常费时。

> 如果是精选的，以 C 的生态，必定是 bias 、opinionated 的

何出此言？

> 仅仅只是一个条目、一句介绍显得过于单薄了

是的，所以我在介绍时非常强调对比性。如果列出了多条项目，一定要找到其差异的地方：是否更全面/紧凑？是否兼容特定 C 标准？性能是否有明显差异？是否维护良好？有关这一点，可以在列表中任意查找验证。

> 同时 OP 应该是专业的 C 程序员，应该在某个领域具有比较深的积累

「我不是专业的 C 程序员」里的「专业」是指「以写 C 为职业」，不「专业」 != 啥都不会… 要是啥都不了解就来写这种项目，我不是给自己找不痛快嘛。

至于你说的「某个领域具有比较深的积累」，我做 Linux 内核驱动和嵌入式比较多，不过都不是公开项目。这一点也可以从列表中验证：网络、JSON 解析部分的库改动是最勤快的，因为这一方面我确实了解不深。

> 否则怎么知道推荐的某个条目是不是这个领域里的常规用例

谢谢你的建议。正如我反复强调的，目前的评选标准是维护最积极、最流行甚至已成为事实标准（当然还包括可移植性、性能等），我认为这些都是客观的评判方式：如果某个领域最流行的库在 GitHub 上只有几个 star ，很「不常规」的用例反而有几千 star ，或者在 StackOverflow 上根本无人问津，那反倒是一桩怪事了。

最后，我发到 V 站来自然是为了让更多人看到这一项目，这样才有可能有路过的「这个领域里的」大佬来提出意见，让我有机会修正为你说的「常规用例」。

这是一个社区共建列表，不是一个个人维护项目。我不明白为什么我被一而再、再而三地要求证明我自己的个人水平或项目的「意义」来为列表背书，因为我的个人水平和列表的质量根本不是一码事。

如果你认为列表质量低，请直接说明哪一条低、改成什么项目更好；如果你认为有更好的选择，请直接把选择甩到我脸上让我学习，不必拐弯抹角；如果你压根没点进去看过项目，只是看完我的描述就想找个网友来怼一怼，那我也欢迎。虚无缥缈的指责无益于项目的进步。

@tool2d #7

> 现在有了 GPT4 ，需要找啥库问它，十有八九错不了。

本着谁主张谁举证的原则，请证明这句话。不然全成我一人在说道了，有偏袒自己之嫌。

如果一定要我举证：(1) GPT-4 不是每个人都在用或者有能力用；(2) 我当然问过这个问题，GPT-4 回复的均是一些年久失修或者在某些 StackOverflow 中回答过的冷门库，反复增加条件好几次才慢吞吞给出 libuv ，而且还是同列在五六项不能用的库之中的。这恰好是我想避免的；(3) 小小滑坡一下，如果 GPT-4 就能解决所有问题，那 GitHub 上所有同类项目都应该不需要存在了。事实是这样吗？我个人从 GPT-4 处获得的回答，有一半都是错误的。

再强调一次，举证责任不在我。如果你想就这点讨论，请先给出任何一点自己的依据。

> 小白不会用，指的是新人很少有用 C 语言写项目的

要么我理解错你的意思，要么你在偷换概念。我们讨论的「小白」就是「学习 C 语言项目的小白」而不是「初次接触编程的小白」吧？怎么这部分人又变成「很少有用 C 语言写项目」呢？

> 产出和学习周期太长了。都是老人在用 C ，他们写的代码，基准在线，很糟糕的 C 代码项目极少。

这些是客观事实。我认为，「产出和学习周期太长」的一个（不是全部）重要因素正是 C 语言生态差，各种配套设施杂七杂八得多，而且质量参差不齐。那么提出一个 curated list 我认为是有益的。

若因此不做，不又陷入「生态差->没人学->生态差」的循环了？而且预想一个完美的庞大「老人」群体（而这部分人很可能没有你说的那么多。看看 GitHub 上 C 库的代码质量就知道了），然后争论他们如何懂，这和项目是否有意义，我认为是关系不大的。总是有人要学习的，我的项目哪怕帮不到别人，能帮到我自己也是好的。