U 盘本身就不靠谱
没有靠谱的存储介质，真靠谱需要多份备份+checksum

试试用 #3 的方法加上 #2 的 HKT

template <template<typename> class A, template<typename> class B>
struct MyCombo {
typedef A<MyCombo<A, B>> a_t;
typedef B<MyCombo<A, B>> b_t;
};

Aa<MyCombo<Aa, Bb>> a;
Bb<MyCombo<Aa, Bb>> b;

搜 variance
另外这个不叫”子类”，subtyping 和 inheritance 不一样

@nasmatic 你需要看大量的 hinative，wordreference 和 stackexchange 才能有初步的理解，并且不同人给你的解释不一样。就别说 hinative，wordreference 和 stackexchange 也有大量对词典的引用，也就是说很多”本地人“在解释的时候也出现了主楼所说的”说不清道不明但你又很难用错“的情况，而这个时候最普遍的 fallback 是词典。
相比来说，词典（主要指英英词典）在极小的篇幅中压缩了极大的内容（这也是词典本身的目的所在），只是读者能不能理解的问题
（你以为英英词典就不是本地人写的了 ...

原因就是词典就是对语言在应用中的经验再总结沉淀为理论的产物，相比于经验来说是更加 higher order 的东西。hinative，wordreference 和 stackexchange 上这类问题的大牛的终极形态是一本人肉词典 ...

我来 generalize 一下楼主的”感悟“：
很多你以为的”技术问题“其实不是”技术问题“而是”经验问题“

扩展：人们是尊重经验的，但我觉得人们更偏向于能把经验抽象为理论（也就是沉淀到”技术问题“）

就楼主的这个近义词问题来讲，我觉得目前词典是做得最好的

楼主这个统计的精神可嘉，但是干不过小屏手机在市场（尤其是 Android ）事实上已死的现状
就像我也有个类似的 CPU/GPU 统计，统计的结果是没一个能买的（嘛，大概 2191B 除外 ...）

”小屏“当然就是指”小屏“啦，不是指正面面积小，是屏幕面积小，正面面积小但是屏幕面积不够小照样没法单手操作（主要是屏幕太长）
”正面面积小但是屏幕面积不够小“（或者”年前对于小屏手机的定义是 5 寸，而 2019 年，把 6 寸以下手机定义为小屏机“）的原因是”全面屏“的普及。但是这个”全面屏“怎么做可大有门道
Apple 把 iPhone 8 的屏幕尺寸不变，额头和下巴切掉再加个刘海算是”全面屏“，Apple 把 iPhone 8 的整机尺寸不变，屏幕放大再加个刘海也是”全面屏“。但是前者还依然能算是”小屏“，后者就不那么”小屏“。（事实是不仅 Apple 走了后者，”全面屏“后的 iPhone 长宽高甚至都又大了一圈 ...）
”全面屏“之前的很多手机在屏幕左右的边框上已经做得很窄了，”全面屏“概念上主要是消除上下的边框（实现中是通过放大屏幕来消除边框），但是对于”小屏“来说，上下边框有多宽其实根本无所谓，他整个 3 cm 的下巴照样是小屏。

你的第二行其实可以归到第一行里面 ...（前提是你在做第二行时没有消费行为）
现实就是 996，以及 996 升级到 007，你只要没有在为社会主义现代化建设做贡献，你就是在逃避现实。

和楼主不同，我认为人类作为一个物种，最伟大的地方体现在这个网站以及它所提出的设想：

http://www.vhemt.org/success.htm

> We’re the only species evolved enough to consciously go extinct for the good of all life, or which needs to. Success would be humanity’s crowning achievement.

> May we live long and die out.

这个硬件厂商玩了好多年了已经 ...
有空多看看 AI 界和医学界大佬 Jensen Huang 的演讲，买买他出的书和课程，支持一下他的燃气灶业务

当然有替用户考虑的成分，Web 技术本来就不适合开发应用，大多数基于 Web 的应用的效果也就那样。禁止了 Web 技术在应用中的滥用，用户的使用体验更好了，续航更长了。
也当然有替开发者考虑的成分，对 Web 技术的限制会增加对 Apple 平台原生开发者的需求，Apple 护自家开发者的犊子，消灭投靠 Web 的异教徒可以理解。

但是我不看好这种用简单的技术手段解决非技术问题的尝试。
iOS vs. Android 的根源其实是个千年老问题：管理者该管多少合适？“自由”的边界在哪里？

@murmur 我的理解，Apple 此举的主要目的，通俗地说就是禁止热更新（应用送审后行为不能改变，或者说与外界通信内容仅限于数据，不能传输程序）。
还有一种可能是遏止非原生框架（包括“H5“）的大量使用对体验的劣化，不过我个人偏向于前者。
所以理想情况应该是封有热更新行为的应用，但如 #48 所说这并不现实。之所以单独拎出”H5”，以及专门扯了一堆 WebKit JavaScriptCore 之类的，是因为使用“H5”和热更新这两者之间有一种奇妙的强关联，基本一抓一个准很少有错的，事实上就官方声明来看已经对“H5“采取了一刀切的手段。

但是我不认为所有类似的跨平台框架都在 Apple 的目标之内，因为”跨平台”和”热更新”根本就是两个正交的需求（虽然可以用同样的技术手段解决）。跨平台框架可以不做热更新。并且理论上，跨平台框架也可以做到把所有东西塞到一个 binary 里面（只是目前可能还很少这么做），至少可以满足技术上的要求（不运行 binary 以外的代码）。
“热更新”（或者广义上的执行非自身 binary 中的代码）也不是禁了已有的框架等具体的技术就能禁的，因为“数据”和“程序”其实是无法区分的。甚至一个程序有没有“热更新”行为也很难界定。

最极端的情况是有实力也有需求的大厂自己造私有的跨平台 /热更新的框架。想到这最搞笑的是，如果真有人用这种方法绕过热更新限制，那就没法做 JIT 的现状和某些华而不实的大厂的真实水平来看，可能最后体验还不如 H5

我觉得 C 语言做到你写出个 nginy 然后被抓就可以毕业了。

@AlanDecode 倒不是重名，OS X 那个其实是 Maverick*s* ...
作为重度 Google 用户，我一般起名字之前会去 Google 搜一下，结果数量太多或者太集中的就不用了

用已有的名字是个很蛋疼的事情，如果项目火了，比如 Opera 浏览器，一搜全都是浏览器，想找歌剧得另外加 qualifier，Switch 一搜全是游戏机，像 Halo 这个词基本就是某游戏系列的专利了，对于对项目不感兴趣的人不公平
如果项目没火或者不够火，比如 Arnold 渲染器，一搜全是施瓦辛格 ... 这对开发者不公平
另外我发现 IT 圈流行的东西，名字一般都在三个音节以内
然后如果我还想要点内涵的话
就发现起名字太 tm 难了 ...

还以为是说 BSD ...

@secondwtq 对了今天王垠又发微博了 ... 虽然重点不在此吧

https://imgur.com/TmvcsVg

看到这个帖子，我意识到我手上这个本装的 10.9 已经彻底过气了

Flutter 跟 JS 有关系么 ...
硬要说的话大概是 Flutter 一大作用是一套代码到处运(tiao)行(shi)，然后恰好这一行目前的领导核心是 JS
我寻思最早叫唤一次编译到处调试的不是 Java 么 ...

@secondwtq
对于不可定制的程序来说，用户觉得哪一处严重影响体验了，那可能就直接不用了。
这就是定制性高的程序的客观优势：一个可定制的软件可以适应更多人的需求。就算用户不会定制，也有各种傻逼包帮你定制。

上面是单就“定制性”这个问题来讨论。当然不得不承认的是，很多 Linux 程序所谓的“定制性”也没多高。理想中完全可定制的程序可以适应所有人的需求——当然这种软件并不存在于一般大众意义上的“软件”范畴中（但是拥有极高可定制性的软件是存在的——就是通用编程语言 ...）。Linux 所谓的“可定制”对于大多数人来说只是 cover 了一些特殊情况而已。