没约定还不是一样要看文档来配置……
约定烂是另一回事，属于设计问题。

再借楼发（跑）散（题）超纲一点，我想特别显示一下在 lang spec 里钦定 phase 这个做法的实际历史性后果，以说明它是如何比 PL 壬沉溺（钦定设计的） type system 和相关研究更优先值得黑的。

钦定 phase 的一个显著后果单方面由语言设计者决定了何为“静态”，而没有用户议价的空间，导致不切实际的无效工作。
一旦不满足用户需要，要维持可编程性，就需要 ad-hoc （致敬 ad-hoc polymorphism ，表示“不一定就是坏的”，但实际大家都懂的）的 reflection 机制来变通。
这种机制基本也只可能由 spec 钦定，于是设计语言时就凭空多出来本不必要的一大坨的 API 设计（经常还没法避免主观性，特别是甄选什么 feature subset 配被 reflect ）的工作：工作量大体 O(n^t)，其中 t 是 phase 数，常量和其它特性正相关。（虽然大 O 是渐进上界，但常数可不小，一般要可用也够受的了。）
大部分语言中 t=2 ，被隐含钦定的 phase 是 phase of translation 和 phase of execution 两个，这也是一般所谓语言是否可被视为“静态”的分野。光是这个就制造出了反射这种原本就是同一个直接语义直接元编程的就能“免费”实现（源语言语法满足 homoiconicity 时）的工作。而 C/C++这种直接钦定一大坨 phase 的做法更加突出了所谓 compilation-time reflection 的更欠抽的“高阶”无谓设计和实现工作量。（当然，C 一直装死摆烂，这里可以算了。）（还好，除了 C++主流语言里还有谁那么乱的么……）
第二个后果是简单粗暴的 phase 蕴含了粗放式分层架构，即便实际的需求中，各个 phase 的问题域具有局域性，而并不要求语言规则具有明确的分层结构。
这是 reflection 这样的机制难以被其它形式的元编程替代的另一个原因。
这里有个类型系统外过于“静态”的例子：hygienic macro 再强，就算 host lang 再 homoiconic ，基本也得多一个 template sublanguage （而增加无谓设计和用户学习的工作量）——很大程度是多了个 expansion-time phase 的锅。
作为对比，bind-time analysis 中多出来的就是 local stage ，不添加类似的缺陷。
第三个后果是对实现结构的影响（不过其实 C 这种传统设计其实算是直接泄漏了实现的设计），尤其是造成片面拔高 AOT 编译的能力的偏见，工程上力大砖飞，搞不好就加人，全然不管项目规模扩大的代价，特别是路径依赖。
（幸甚，multi-staged ML/reflective Lisp 之流从来不成气候，所以毒害的主要也就局限在传统“静态”语言实现了……）
当年编译器理论界对 nanopass 的普遍怀疑也说明这不仅仅是工业界见识短的问题，“理论界”也整体就跑偏了。
近年来 PyPy 和 Graal+Truffle 这样更正统（指 variants of Futamura projection ）的计科传统艺能（指无情地自动化加抽象）重新上线，让一些实现者认识到现有方法论的欠缺（你人再多能打得过自动化翻译解释器成量产优化编译器么），算是自底向上地打了脸。
遗憾的是，这个问题在工业界距离彻底纠正差得远了：可预见的未来内要指望主流工业界开窍避免依赖 GCC 和 LLVM 这样的力大砖飞式历史包袱是十分不现实的。

其它理论碎碎念：github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#phases-and-stages （关于这些问题如何破坏语言的通用性，Ctrl+F smoothness 。）

@dangyuluo 这就是哪壶不开提哪壶了，C++的那种强 phase (of translation)隔离的做法反而是最让我火大的糟心解。
虽然表面没 OP 的问题，实际上更恶心了：用户完全被剥夺了跨 phase 表达同一实体的抽象能力。
比如就想要精确表达 10 这个抽象的数，用 C++源码是做不到的。传统的 C/C++中，用户被迫在 pp-number 10 、integer-constant 10 作出抉择，而 C++加了一种介于两者之间的、光是语法上就明显更欠扁的 integral_constant<int, 10>，更加混乱（考虑到 template-template parameter 的无能，metafunction 不方便 partial application ，integral_constant 第一模板参数还特别不方便参数化地使用，更显得 int 这种“强类型”就是在没事找抽刷存在感）。
结果就算不考虑被静态类型污染的问题，真要通用，就得向上游迁移——及早确定然后顺下来给各个 phase 用（还照样省不掉显式“转换”），实际就意味逻辑就尽量塞预处理器了。这也就是一个整数，如果塞不进预处理器呢？
（想到 endianness 没法尽量只靠可移植的 template metaprogramming 实现最后还是得 std::endian 加 pp phase 层次的魔法这点，就气不打一处来。）

@codehz 既然都会加标记断言了，那为什么不更进一步，直接用 contract 而不是变着法子搞什么 refinement 得了(cf. Racket)？
到了这一步，这里真正麻烦到值得计较的反而是怎么确保 proper tail call 之类的更全局的性质，大部分类型论特性反而不重要了。

所有（静态）类型系统在遇到类型规则不符合需求时都会出现这类问题。越是如 Robert Harper 强调“静态”的正统性，遇到这个问题越会诛心。
这其实是大部分搞 PL 的都没搞清楚的实用通用语言设计中的核心问题（关键词：intrinsic and extrinsic views of typing ）。相比来说，大部分 PL 壬所谓的 soundness 、totality 之类的问题，是很次要的。
根本解决方法是在基础设计中完全放弃带有静态类型系统的静态语言，让类型系统规则自身可编程。
作为魔改现有“无类型”动态语言发家的 TS ，恰恰是所有语言中这类问题最小的一类。不过即便是这样，要绕过去也基本意味着用户需要自己实现 JS 到 TS 的转换，因为 TS 的设计没有考虑到它自身这部分足够模块化而让便于用户复用（做成 JS 或 TS 的库），以节约重新实现类型系统的开销。
顺便，所谓 gradual typing 只是一种妥协，原则上并不确保用户可修改类型系统规则。

@Zerek +86：？

我顺便提一下，pmr 用起来可能有个常识性的坑 OP 不知道有没有绕过去了——copy 容器时 pmr polymorphic_allocate 不会 propagate ，因为 pmr::polymorphic_allocator select_on_container_copy_construction 会返回默认初始化的 allocator 。
如果没注意，复制（包括传参和返回）容器对象时没有显式使用 allocator 或者 uses_allocator allocation ，退回到默认 new_delete_resource ，不但基本是纯粹的性能回归 bug ，还可能会在 swap 等操作中凭空多出 UB 。
一旦已经注意到这个问题并正确实现，前面一些回复的手动加 buffer 的实现改起来差距就大了。

@ipwx 你说的思路粒度太大。从 OP 的描述看，我不认为这没被考虑过，倒是一些坑没被说，所以提了一下。
我说的其实也不十分细（而且不怎么对口，跟 mimalloc 的目标领域倒是强相关），不过既然 mimalloc 都被 OP 认为看上去有帮助了，所以也没多计较这个。
要说优化，是十分有讲究的，跟具体负载关系很大，坑也各自不一样，所以没有具体的代码也没法说得很细。光是怎么踢出去的策略，实际表现的上下限距离就挺大。如果非得不限定场景，那么只能说 pmr 里的 pool resource 基本算是 C++能用的各种意义上（除了具体实现的坑）最高效的了。
（这里还是排除复制 allocator 的问题。理论上更高效的是用 keyed static variable 之类比 thread_local 更扩展的机制避免要求有状态 allocator 的复制，但这个不是得改核心语言中很基本的规则就得魔改 ABI ，C++范围内就算了。）
至于碎片，不是用不用 allocator 的关系，是只要算法不能确保完全静态确定分配，这总是会存在，无非是怎么把问题变小。mmap 之类用好了可能解决问题，但太不具体（ OP 不给代码也没法具体），而且实际上不太容易用好，不仔细优化极可能有空间利用进一步下降的代价，照样可以加剧原始问题。

@mingl0280 OP 既然都用上 pmr 了，表明实际代码很可能难以套用你测试程序的方式使用，“简单方便”是很可疑的。
这种情况下，只要大的方向（最底层用什么分配）正确，随便一个输入数据和实际生成优化代码的不确定抖动都可能让这里的差距化为虚无，缺乏显著性。
考虑到 OP 似乎只用 trivial copyable 类型的数据，你的方式不是没实际优势——对编译器优化的不确定性小，编译开销也小。但这也就是确保能改得过来，而不是一定更好。

@em70 罗永浩：？

问题不成立。
A<B>里的构造函数直接取决于 A 的定义，而不一定依赖 B 。你不给 A 的明确定义，这个问题就无解，上面的多数回答也就是在这个基础上瞎蒙（假定 A 的构造函数里会初始化 B ）。
有没有依赖 B 的构造函数都是个问题，就更别说有没有依赖签名为(int, int)的这个重载了。

@FrankHB 最后一个 URL 有误，应为#L647 ，指局部 optimize("Os")生成 x86_64 代码中少了 15%的指令。

monotonic buffer 是只分配不管释放，除非最后整个干掉。如果不是严格需要单调行为，一般应该用 pool resource ，而不是放任让空间更加紧张。
不过这里 std::pmr 有个坑是不保证一定会释放，允许 pool resource 也实现成 monotonic ，算是 QoI 问题，虽然没见过实际实现这么贱的。我提过 issue 然而 WG21 那边没怎么鸟，我也懒得跟了。
因为这个原因和 C++11 依赖我用自己实现的兼容 std 的版本（以及某些实现的细碎 bug ），加了些扩展：github.com/FrankHB/YSLib/blob/master/YBase/include/ystdex/memory_resource.h 。

@ipwx 就跟智能指针不总是负责所有权一样，显然不是“只用不扔”。pool resource 就是主要改善局域性和减少碎片，不一定说的是不扔。反倒是默认不扔会有上面的可用性问题。
mmap 滥用一样可以有虚拟地址空间碎片。

@cs8425 mimalloc 是几个比较强的实现之一，不过多线程通常不如 snmalloc 。
mimalloc 预期的典型负载是动态语言运行时。对充分使用 C++ allocator （其实会因为复制 allocator 吃寄存器带宽的亏，先不管了）。一般表现和 MSVC 实现中的 pmr pool resource 类似。前者的优势主要是折腾的姿势多，但是这里似乎也用不到。
我实现的 pmr 也比较类似 MSVC ，还偷懒了一点（少了个 intrusive 结构，直接复用 vector ）。不过针对负载调整（ github.com/FrankHB/NPLC/blob/master/NBuilder/Interpreter.cpp#L389 ）后基本能碾压 LD_PRELOAD mimalloc 了。
opt-in 了编译器相关的优化（ github.com/FrankHB/YSLib/blob/master/YBase/source/ystdex/memory_resource.cpp#L267 ）还能更快一点。

@LANB0 所以不是你说的函数是指针么。如果是语法糖，那么只要没语法错误就能够直接替换。实际呢？
所谓语法糖就是能只需要遵从语法规则，在早期替换而不引起含义改变的严格意义上的“另一种写法”。任何引起语义规则介入影响正确性的，任何多引入未指定行为的，诸如此类，都不配叫“语法”糖。望周知。

@Buges 不累，因为你所谓的理客中的姿势，我真一点都不需要装。
真说累，我倒是得更想装得不像天龙人一点，免得从能做的事的差距就诱使旁人理客中地想象到你为何不得不比我无能狂怒得多了。但我并不会因为比你多做一些事而愉悦，于是这样会显得我试图与你的平等对话是装的，而两边都是小丑。
何必呢？

你是不是想要说服反对你意见的人呢？大约你自己也不信能有多成功吧。
更容易让你容易陷入抑郁的是，与你一样想的信徒到处都有，不缺你一个，但你又没有能力团结他们来否定异教徒。

你对需求理解也是一开始就错得离谱。
我不清楚为什么评估工作量时有意无视结果，推测需求你却反过来根据别人事后的概括的优势去做不靠谱的逆向了。
这种不可靠是可以让你的主要结论归于虚无的，你却要用“工程经验”瞎猜，可真是大聪明了。
可能又只是你彻底外行不懂罢，以至以为工程问题只有技术合理问题了。
其实原始需求是什么根本找不到确切公开资料，反正搞不到一手需求文档（这可不开源）。但反过来“原始需求不是什么”却相对容易推断。很显然完整版需求不会只是你提的几个细节。阴谋论一点，原始需求其实真是个 KPI package 也说不定，而“读写缓存、可选压缩等功能”只是上面的负载（这当然比改注释的 KPI 高明多了）。至于为啥恰好是这几个？正是“工程经验”支持这种现象未必就是技术原因造成的，甚至可能只是纯粹的偶然。
其实是不是支持阴谋论我无所谓，因为(1)我不是当事涉众，不对这里的决策负责也不怕因此风评被害（理客中不需要装+1 ）；(2)查无实据，也拐不住你的“立场”问题上。
(2)也许对你不显然，所以多说一句：照你的思路类推理解，UNIX 一开始多出来的功能不也是改改 Multics 之流就能实现的么，那么新设计个 UNIX 重复造已有轮子又有什么用呢？不是 UNIX 设计者立场有问题，妄图分裂开发者社区，破坏 Bell Labs 和外部的大好合作局面？
当然我没钦定 erofs 能取代 squashfs ，但相对地，你也没什么技术经验能证明这一定不会发生。

这里我不会采取 biased 的立场是很自然的结果，因为两边都不是我的工作，对我也没有什么明确威胁。而一般来说，大众也会觉得多一些同类竞争扩大选择余地是好事（所以你的观点在这里又脱离了群众路线）。不过看起来你似乎觉得 erofs 对你有威胁让你以后的可用技术不安稳了（要真如此那评价还真是高啊）？
但那充其量也只是你的一个具体立场，这可不会让反对你观点的人的立场自动和你对立互补。要有跟你对立的立场，也是我尤其看不惯你这种胡搅蛮缠，禁止跟你不一样观点的人就必须相反地 biased 的脑补罢了。这种常识还望周知。

你对“自主可控”的妖魔化的执着倒是出乎我的意料了。我不是 big brother 本 brother ，不表示当局意见，宣传口上也另说，但是实际上管得着这东西的，我还真没见过（敢）像你这么自嗨的。虽然爱信不信，不过起码别把别人都当傻子。
（或者你说说你能脑补出想按你这样“自主可控”的东西现在具体确切包含哪些么？）
所以你强调的“广泛使用的场景中所指代的”（暂且不说“含义”）对我就只是个刺耳的笑话，偏偏你还绕不开了……我能说啥呢？
我只能说……“自主”“可控”本来就是有单独内涵的，你强行专名化这样毒害汉语的行径，以及眼里只有“宏大叙事”而否定任何个人对此的工作的态度，我坚决反对。
“诡辩不能改变客观事实”，原话奉还。

关于 RMS 的那些争议的评论成功体现了你不算 RMS 那些自由派里的正经人，只是碰到了一些皮毛的小鬼的事实。
要真是他们的同志，那真不该有你那么离谱的一些“立场”错误。
这说明你所谓的“自由”跟自由软件运动的自由根本也八竿子打不着。
我本也没指望这种近似钓鱼的提法能有什么成果，但你自己上钩就别怪我咯。

你要区别你无意的 bug 和有意的 adversary 是你的实现问题。这种实现明显浪费资源而低效，在我看来，算是近乎 feature of last sorts 。你只会依赖这种策略，是你比较初级或者说无能的一种表现。
我本不需要嘲讽奚落你而更应该同情你没有选择的余地，以至于都没有余裕对付意外的 bug 了（即便可能真的更危险）。但是你非得以“继续装看不懂”的方式反客为主、颠倒黑白，那我只能说：你大约更接近野蛮的猴子而不是文明的人类罢。
这不显而易见么？

至于 Web 的“标准的话语权”，你更找错人了。我黑 Web 好多年了……
要我说，Web 这种没法自然维护自由、自动被集体主义的玩意儿就不该作为标准，从成了事实标准起就直接都能当 enemy 了。或者你可以当这里有个破窗效应。
你现在才闻到了反乌托邦的味道，晚了。
就你这样的认识，也好讨要别人施舍的“自由”？你觉得你这样的觉悟不是比我更弃疗么？
而且不说“开源生态”先天内讧的基因，Web 还真代表不了几个有全局威胁性的开源生态。
Web 真烂了又咋地，整个扔了不行？至于 IANA/ICANN 那些，没那么好渗透，倒是不断被垄断企业通过应用业务方式架空了。
我现在不太热衷关心这整坨破烂，除了觉得没救，主要是因为 Google 在进一步做坏事上本事不够，光是基建方面，什么 Chromium OS 什么 Fuchsia 默认当作和 Go/Dart 一样已经寄了。相对来讲我更担心 Apple ，更甚于各种 big brother 之上。
这年头任何能被外部抢到话语权的团体比起水泼不进的垄断企业来讲，这方面都是弟弟。

好像没人直接回答标题的字面问题。

WG14 N2176
5.1.1.3 Diagnostics
1 A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined. Diagnostic messages need not be produced in other circumstances. 9
9) The intent is that an implementation should identify the nature of, and where possible localize, each violation. Of course, an implementation is free to produce any number of diagnostics as long as a valid program is still correctly translated. It may also successfully translate an invalid program.

注意最后一句话。

@LANB0 你在说啥？函数是什么鬼指针，你 sizeof 试试？
又有几个语言有比 C 的得 [] 更加标准的源语言层面的纯语法糖而不是混了坨 unspecified 没法一一映射实现的？

@Buges 关于 Web ，你有一点说的没错：Web 不是我自主可控的。起码出现终产者前，没有一个个人做得到。
从计算资源分配来看，不可控符合一般的伦理：骨干网和 Web 服务器里没我几乎没怎么投入资源去建设，我也没脸直接要求控制权。
但这里限制我自由的根本不是因为我缺少资源的所有权，而是侵害自由的实体对我合理利用资源的干预。
理想情况下，健全的网络应该具有自发维护访问自由内容的拓扑结构。现在呢……随便控制个跟你表面八竿子打不着的关键节点就能让你断网。
那么结论就是，不自由的一部分来自 Web 的天性；要鄙视不自由，就顺带把 Web 鄙视在内了。
那么为什么不自由的 Web 还能 dssq 变成无处不在的基建呢……是谁在容忍不自由的扩散？
（还记得我提过么，Web 不是没有替代品。）

顺便，我能修改 Chromium （虽然太屎了我没选择改这个），实现的是在我控制的计算设备上的自由。
Chromium 相对于其它同类项目更加被鄙视，一个重要原因恰恰就是在 Web 之外更加实际有效地剥夺用户的自由（其实要论对 W3C 和 TC39 之类的影响，该集中鄙视的是 Google 而非 Chromium 单独一个项目）。例如，假定多任务操作系统上 Chromium 就比其它应用更“高贵”而肆无忌惮地优先抢占内存。
这种直接伪装人畜无害地竞争计算资源的策略比个别恶意限制你访问还离谱多了，因为无差别恶心所有用户，而其中大部分人是没能力改变这种状况，甚至根本发现不了损失计算资源的原因，搞不好还会嘲讽捍卫自由者：“内存就是应该拿来用的！”
Web 不过是这种恶心状况的放大版罢了。这方面我只能建议你先扫自家门前雪罢。
（其实这种状况何止 Web ……Android：？？？）

@Buges 首先，我拒不接受你所谓的立场之争的定性，特别是你还在扣别人“不懂”贼喊捉贼的同时。
如果非得认为有立场，那么情况就是——你在宣扬反智，以你狭隘的偏见来覆盖正常人对“立场”这个汉语词语的外延的理解；而我和许多其他人不用关心你的“立场”的其它具体内容，在这里就已经站在你的对立面上。
一般强调立场，同时蕴含着分歧的正当化。即便我并非要摁着你的头让你对不同的不当观点认错，你也应当明白不是所有观点不同都能让你轻描淡写地以“立场”糊弄过去。
不好意思，我一开始就对所谓的“立场”毫无兴趣；你应当认识到，你没有资格把你的这种狭隘强加于和你平等交流的正常人的观念之上。
你有意地把类似意识形态为纲的“立场”凌驾于其它分歧之上，贬损其它值得讨论的问题的价值，通俗点讲就是坏。
有人把你当作民科批判是比较轻描淡写的了；民科主要是指无知的蠢，但平均可没坏到你这个程度。

其次，你所谓的“装看不懂”的结论，应该就是你的立场论调的消极后果的体现。
我是在哪里装看不懂，看不懂了啥呢？
还有哪些方面，有你想到的而我没想到的东西呢？

第三，我不懂，那么你懂？
我反复强调过一些解决实际问题的目的出发工程常识的问题。
之前我早就简单说过这点，你仍然是一副所谓“刻意离题”的态度。
你的所谓“建立加密信道进行网络连接的人，屁股……”不是更加离大谱的题？
（老实说我得向 OP 道歉，没能解决主题而跑题了，不过 OP 看来也乐于看到你吃瘪，就先借地方不污染外面了。）
就先不说你坏了，这里只能认为你是真不懂。不是纸上谈兵，是外行瞎指挥。
什么叫“扩展的工作量必然小于完全重写”？你搞清楚原始需求了吗——里面有“扩展”什么？
你的观点充分体现出你在臆测。如果真够有常识，那么就该意识到已有的东西和没有的东西是两回事。除非需求不是直接明确要求扩展，那么扩展现有设施的复用或者另起炉灶的决策相对于需求就是实际细节，两者不是先验地互相可替代的。哪来的“必然”？
已知这里的需求明确就不是“以 squashfs 为基础扩展出新的 fs”（撑死就是扩展 Linux 的现有的更加基础的设施），新的工作和已有的 fs 是并行的。所以度量工作量根本和已有的同类工作无关，看的就是这件工作自身——要么是详细的设计和实现的计划，要么干脆就是看结果。你这么做了吗？
反过来，如果你直球钦点 erofs 缺少进步而接近无效劳动，乃至就是“垃圾”，我在这方面不会那么鄙视你。毕竟我还没空整体评审这些方案的不同，所以你大可以生造我不清楚的细节——但这方面的思路看来已经被其它回复堵死了。

第四，我没兴趣继续跑题，不过揭你逻辑的短很过瘾，那么继续。

> 这就叫“卡脖子”
> 这就叫自主可控
> tls 是不可控的
> ……这就叫自主可控

给出引用来源，或者不是你原创研究脑补的论据。

> 导致我们无法区分合法和非法流量

“我们”是谁？

> 开源社区是包容的

提醒你一下，这不是事实判断。有疑问可以另外解释。

> 被某实体设计和主导开发方向的代码越多的进入开源社区，某实体的话语权和可控程度就越高，这就是对开源生态的污染。

这是你的“合理推测”。不过你确定你所谓的某实体有能力做到什么程度呢？

> 在这里掰扯 RMS 那一套没有什么意义
看来你是反 RMS 咯？
我提 RMS 除了（口嗨）黑 RMS 外，主要就是拿来当对号入座的标靶。你亲口承认否定了自由软件运动的最主要流派的立场（这里是正儿八斤的“立场”），表明你其实就是叶公好龙或者小鬼，如此甚好。（反正我也不和 RMS 穿一条裤子。）

> “自由” by definition 就是不被任何实体“可控”

这就是你被害妄想式的捉急汉语水平了。
容我直接鄙视你一下：不由我“可控”，谁替我保证我的自由？只能指望物理定律吗？
你凭良心说，实际在跑的代码，里面你自己能看清楚的部分，不比别人（甭管这些人是什么立场，反正不可能是你的克隆体，更没义务和你的思想同步）替你亲自看过摸过的更“可控”？
哦，你要是没本事看懂，那倒是一样了。不过，这样的你准备损失多少热脸蹭“自由”的冷屁股呢？
当然，你还可以强辩，虽然自己看不懂改不掉管不了，但是别人和别人之间也是不一样的。你选择以“立场”决定哪些人更值得相信，那是有效接近自由的趋利避害。
逻辑上这没问题，不过至少我是有资本自然鄙视这些劣等方案的。
你能臆想出来的谁比谁更值得信任，很大程度就不是客观实在。大家都是 as-is ，谁需要在乎你？
说到底，你的概括“立场”的能力，撑死仅限识别有限的极个别的恶意，而且因为你不是什么重要的目标才正好能让你以为有效（虚假的接近“自由”的安全感）而沾沾自喜。
反过来，我原则上就不屑区分有没有被恶意针对；无意的 bug 一样会坑到我，而让我严重损失自由。直接按风险和后果排序，把可能的威胁一个个摁死，是更直接的做法。
标识恶意是一种维护自由的手段，本质上和其它更积极地追求自由的目的没有什么区别，但当不被明显针对时，积极排除恶意的性价比极其不划算。就像社工也是攻防手段的一种，跟利用密码学实现一些目的上本没什么高下，但作为防守方，当明显的低级错误被排除而不值得被针对后，无视弱口令风险而继续盯着这块不放，就极其愚蠢了。
那么在这里，到底是谁更能接近自由（你说的，不管怎么定义）？

@Buges 1. 没有必要多讨论你的被害妄想。这个问题上有立场的话，差异也只是是不是反对你的立场。
（你要还硬认为这里有人是支持 KPI 项目的立场，那是另一个妄想了。）
2.明显是你没理解这个含义。
Linux 加个文件系统是“小小”的功能增加是不是你一家大言不惭我先不提（毕竟硬说的话你“小小”到一堆 return ENOSYS;技术上都能算加了文件系统的实现），变成微内核算颠覆性重写也没什么疑问，但是提供新的实现到底是小不小，根本上跟原有功能多大没关系，除非你证明新增的东西就是基本从原有功能抄了一份没加多少改动。你明显没支撑起你的观点，这是你基本的逻辑硬伤。
你的进一步的硬伤在于，没认清（或者有意混淆）是不是“小小”和你认为有没有价值这两回事。反正源码树就在那，是不是“小小”就没多少主观判断的余地。要按你的说法上纲上线，我就得怀疑你是根本不懂如何判断工作量的问题强行乱杠了。
3.明显就有问题。我一开始都没表态自由应该有什么内涵，只是直接跟现有的现象对号入座罢了。你表达的所谓理念不仅没完全分清楚自由和开源非自由，而且连“正统”的抠脚皮大汉式自由都算不上。（黑 RMS 是顺带。）你想欺负这里没人比你熟悉自由软件运动吗？

“某国”的价值观，某国是自然人？谁授权代表的？

至于自主可控，倒是你屁股问题了，显而易见。
不巧，我就认为自主可控的主语是我，因为光说软件，我还刚好真有单人直接“可控”地全生命周期地部署许多我日用的关键应用的能力——必要时我甚至大都能自己实现，阻碍我的只有物理原因；或者就算这个应用不是我自己写的，我至少比这里大多数人（应该包括你）都更能做得到更接近完全自主。
（讲个笑话，我都有本事以不输于原作者的深度审查许多你们用的开发技术的理论依据到实现，同时重新发明你能想到的绝大多数日用轮子，要是全栈到这个程度的我都做不到可控，这个星球上又有几个人能做得到？ RMS 能？他先糊个 operational semantic 检查一下 C spec 的漏洞？）
正因为你根本就忽略了这种可能性，所以才先入为主地认为需要有某些组织和群体的保障才能保证可控，然后把我和某组织对立起来，却完全没注意到这两种“自主”算得上两个次元的东西。
不过，就算合二为一，你怎么就那么清楚，我完全没能力收割别人的成果呢？不过是比起我自己亲自“自主”，耗费资和信任成本的开销导致效率比较低罢了。
你所谓的理念，特别是提到的那个什么 reputation ，说白了也是这种机制：因为自己控制不了（我自然是不能完全控制每个我摸过的软件，而你怕是接近完全不能控制），所以选择相信有 reputation 的人干活承担风险。
这里于我的问题有两点：
那群人再怎么有 reputation ，也没义务配合我的需求；
代码又臭又长，神仙也救不了。
比开源“多”出来的“自由”的作用就是避免有人藏着掖着而已，同样不能解决这两点的根本困难。（而软件方面，我都不屑于管有藏起来的东西，控制不了隔离就是了，真有本事物理黑我的还用雕虫小技刻意恶心我？所以这种自由对我来说没多大用。）
你所谓的资源不如我能摸得到的东西，我干嘛觊觎你的屁股？你要在这里被害妄想我也没办法。

我不反对对自己本事不够自信的用户无脑走群众运动路线。不过，你走的路线现在看来也不是那么合群的了。