1. 「一次性按照科学方法设计好」是谣言。

QWERTY 键盘基本是逐步演化而来的，一段时间改一个按键布局。具体可见上面科普中的参考文献和历史资料；

2. 「 QWERTY 就是为了避免打字机卡键」或「为了降低打字速度」是谣言。

「为了避免卡键」疑似可能，但仅仅是演化过程中做部分修改的一个考虑因素。否则，为何按键频率极高的 ER 组合被设计在一起？「降低打字速度」客观上起到了这样的作用，但说这是设计目的，则是纯粹的胡扯了；

3. 之所以 1 、2 这些谣言遍布广，就是因为没人愿意认真听和传播一个近五十年的键位演进历史，多枯燥啊。「避免卡键」四个字一下就说完了，朗朗上口。

4. 求真务实地说，QWERTY 键盘没什么神秘来历，就是一条最无聊的、设计师们考虑当年打字习惯和使用方便而来的复杂演变过程。

Only Google Can Do!

这是给 Firefox 送子弹啊

@qbqbqbqb 也许吧。但楼主看到却没有回复我这两条，也没有更改自己的问题，那就默认楼主知道自己在说什么吧。

@w568w #12 再补充几点：

1. SHA256 不慢。一般人说「 SHA256 慢」，也不是因为算法本身过于复杂；
2. 不仅 SHA256 没有，RSA 也没有「几百万次循环」；
3. 摘要算法不存在常规意义的「破解」一说。一般说有安全问题都是指证明了不具有抗碰撞性、抗第一原象性（这是一般人理解的「破解」，即从摘要值恢复原文）和抗第二原象性。目前基本没有摘要算法被「破解」。

更多摘要算法介绍可以看这篇： https://thiscute.world/posts/practical-cryptography-basics-2-hash/

@valord577 我猜你说的是 RSA ，一种加密算法。SSH 的安全加密是 RSA 算法完成的，SHA256 只是用来确定指纹。

另外 SHA256 是「摘要算法」，不是用来加密的，和加密算法除了都有「算法」俩字，根本没半毛钱关系。在不改变原义的情况下，摘要算法永远是越快越好、越优化越好，所以才有那么多硬件加速。

最后，SHA256 （包括很多摘要算法）本身根本没有什么「几百万次循环」，那也是加密算法才考虑的。不要被楼主一知半解的提问误导了。

首先一个根本性错误：SHA256/512 依然是速度优先的，根本没有什么「循环 100000 次」的过程，中间每个 chunk 最多也就循环 64 次。

对于「循环 100000 次」的问题，楼上说得很清楚了：次方还是对一个数做 N 次乘法呢，你能化简次方运算为 1 次吗？

回到正题，加密循环可参考这篇文章： https://blog.csdn.net/u011583927/article/details/80905740

总的来说就是右旋和位运算叠加的过程，原理上来说因为要读取整个文件（而不是什么「循环 100000 次」），不能化简。

@TimPeake 玩机的人和普通的用户追求不一样啊。你要易用性当然可以全用系统应用商店，但玩机为的不就是手机用起来更舒服吗？为了这点舒服，自然有人认为折腾是有必要、有乐趣的。

你不应该和玩摄影的人说「说好的一键拍照呢？你们这么摆弄相机累不累啊」或者和玩钓鱼的人说「天天摆弄鱼竿饵料累不累啊」，一样的道理。

挺好的，几个补充：

1. 搜索问题请用英文，中文搜不到或搜到垃圾内容是常态，搜到正确答案是走运；
2. 另外这种包装作为语法糖性质的东西，本就应该先了解原理再使用（没有说楼主这篇不对的意思）。先用再了解原理或者根本不学习原理，生活处处是魔法。

C/Zig/Rust/Go 占内存都小。说到底为什么要吊死在 Java 上？你也知道资源不足，还用企业级的 JVM 。要么 GraalVM 编译为原生，要么等 Kotlin Native 吧。

我的一般顺序：

1. F-Droid 找开源构建
2. Google Play 找国际版
3. 华为应用商店（在国内算审核比较严格的了，最早强制要求 64-bit 原生的应用商店）找国内版

从 Type Theory 来说结论早就有了：Go 的 Prod type 抽象就是错的。

在错误的抽象前提下，不管讨论什么都是错的。我就不掺和楼主对具体情况的讨论了。

正确的抽象如 Rust 、Zig 、Haskell 都是 Sum type ，即要么 Value ，要么 Error 。

====

先打预防针：我猜肯定会有人 Argue 说「难道你不考虑既有错误又有返回值的情况吗？」，拜托，那应该是 Value | Error | (Value, Error) 这个复合类型，怎么也轮不到 (Value, Error) 吧。即使 (Value, Error) 确实从结果来看「巧合」地达成了复合类型的结果，后续处理中也依然要分成 value != nil && error ==nil, value == nil && error != nil, value != nil && error != nil 三种情况来处理。发现了吗？只不过是在重新发明 Sum type 用一个 pattern matching 就能搞定的简单任务罢了。

单就前一个需求（嵌入资源），C23 已经标准化了： https://zh.cppreference.com/w/c/preprocessor/embed

@zhng920823 #6 CMake 被大公司推行的好处是能统一。另外，Meson 作为纯社区项目，其实没有被大公司裹挟吧？

我也喜欢 xmake ，还贡献过代码。xmake 的问题可能是包装得太深了，想要做一些自定义很困难，以及没有一个 CMake 级别的 behavior reference 文档。

什么乱七八糟的，弱智就弱智，弱智喜欢啥品牌都是弱智。为何起吸引眼球的流量标题？

@zhng920823 是啊，我知道可以用，我自己也不是没干过这事。后来换到 CMake 、Meson 才发现：干，这些事原来根本不用自己操心维护。Makefile 里判断平台大多是白忙活！

别人写了十几年的轮子了，兼容性自然远高于我们手写的几行 Makefile 。与其遇到一个不兼容问题修复一个，不如直接用现代化构建工具。

另外，只有第 3 个缺点和 autotools 有关啊，1 、2 、4 点 Makefile 都有。

要我说 Makefile 这种东西早就应该扔进历史垃圾桶了。

多亏了 Autotools 家族：

1. 直到今天 C/C++ 项目的构建和编译还是充满了不在文档中的命令行参数、不知名的环境变量、随心所欲的模块管理和依赖地狱；
2. 甚至每个项目都不得不自己编写一个 INSTALL 或 BUILD 文档来专门教别人如何编译；
3. Autotools 既不通用也不思进取，直到今天依然和 GCC 、glibc 强绑定，AM 宏语法残缺不全、极难理解，并且只支持「 GNU 认为你只需要」的寥寥几门语言和功能，充满了 quirks ，和其他语言的互操作更是无解问题。说是公共构建工具，更像是一群 geeks 自己开发自娱自乐的产物；
4. Makefile 完全没有考虑不同 Shell 和 Platform 的问题，想要跨平台编译，开发者不得不自己考虑并编写几百行的 boilerplates 来适配新的构建平台（例如 Windows ）。

CMake is better, and Meson is even better.

如果你需要一个命令行运行器，你应该用 just 或 ninja 。