@nannanziyu 9102 都快完了，不知道 ps1 兹瓷不兹瓷&了啊……？当年 chcp 65001 爆炸修了几年来着？

@efsg Win10 的 OpenSSH ？算了吧……原生的两套都试过，愣是没法用密钥登录。

@eugenewangfw 有机会成本，还不够浪费么。
不过区区几年博士，比起本科以前沉没成本也算不了啥了。

把你现在觉得能忍受的任何方案里比较正常的部分瞎改得蠢一点，不就马上比较出来了……

@tzh476 因为不像 C#这样有提供 unsafe 之类的，我也不太清楚纯 Java 怎么有意义地（类似实际的 JVM 实现的行为地）允许实现包含分配的自举 GC。理论上也许可以 NIO ByteBuffer 之类的对象分配好 pin 住或者干脆 JNI 直接搞 heap……不过这样多此一举大概还不如直接整个模块用 C++实现了。

一般意义上的 GC 是包含 allocator 的，看了下这里 GC 就只是 collect 算法的实现？

误导另说，但是有一点我不太同意这里的设计思路，就是单纯的“是”和“否”的 UX 未必就更差：不突出简单的“是”和“否”而以具体操作取而代之，反而阻碍关注点分离。
关键原因在于“是”“否”是对话框的标准元素。和 WIMP 被接受一样，这种套路非常容易训练，习惯以后相对高效。而改变这种套路需要成本——遇到一个对话框，用户从看对话框的文本标签变成了要分散注意力看两到三个地方并且分别理解综合以后才能确定实际上做的是什么，越是熟练的用户对这种不分场合的低效会越来越不爽。
更显著的例子是安装界面，本来一路“下一步”好好的，要是非得按这个思路把具体做什么在按钮上写清楚，那就呵呵了。（安装向导不应该有过多的步骤而使这个问题变得不那么重要，那是另一回事。）
另一些次要的问题是阻碍 UI 自动化（不管是开发测试还是用户使用），并进一步拉大 UI 和 API 之间的隔阂。这里有一些交互设计更高层次的哲学问题（界面应该是服务谁的），姑且略过。
所以这种设计原则上应该只在故意要求用户停顿的确认界面（ dangerous zone 之类）中才鼓励使用。卸载……姑且算是吧。

@augustheart 哪里哪里，我连某乎和 LLVM Phabricator 的号都没有，Reddit 和 std-discussion 上的东西也基本没人看（虽说本来差不多就整个是凉的），大概 red 不起来了罢（

不是实用和功利的问题，是实用和功利得太烂的水平问题。
真功利到家，就应该对“先上线再说”带来的风险和机会成本锱铢必较，并且保证能对预测失败负责。只不过大多没这本事，就糊弄过去了。

@Salvation ryf 挨婊和前端圈大概没什么必然关系，因为这人还经常在无关的话题（比如法律常识）好为人师以讹传讹，所以一定程度上众矢之的已经是出圈了。
要说有关系，就是前端圈提供的信徒特别多罢——而不是网红本身的数量多了。

@augustheart C++的圈子？不愁着变现也和网红圈子没差多少罢……
比如像 Bjarne Stroustrup （大作 P1408 ）、Herb Sutter （大作 P0707 ）（下略）这些看最近一些产出不就是流石网红嘛。
（不去倒腾 P0534 这种去搞什么 co_shit 不就是这类网红的调调嘛……）
……哦，不好意思，国内……那可能是要更关心点如何变现，而且确实好像都不成功也没这种存在感。

操作系统不需要实现如何实时反应。典型的分时系统反而有延迟，还就不是实时的。
真正需要实时响应的场合由硬件实现保证。
处理器的中断是可以异步触发的，中断服务例程也是硬件原生支持的异步调用。发生中断时，控制如何转移到中断服务例程根本就不用操作系统关心（操作系统看到的就是硬件自己把内部状态改了，接下来执行到了不同的位置）。操作系统需要做的，是在初始化时指定处理中断的逻辑，以及在此之上实现调度器。

我发明一个新技术，我还要先“使用”才能吹 13 ？？？

@Cu635 现代的 ISA 中所谓的一一对应是一厢情愿的给 noob 灌输的简化，技术上就是错的。
随便举个例子，AT&T 汇编助记符的后缀，你确定能怎么和任意 ISA 的机器码对应？
再如，Intel IA-32 汇编的助记符是可以看成重载过的更高级的简化版本，但是光是指令前缀的使用就依赖处理器当前的操作模式，和机器码不可能简单对应。
在常见的实现中指望一一对应，要么是不懂汇编，要么是不懂机器码，要么是两个都不懂。

一个人手里拿了个馒头和窝窝头的虚像，告诉别人说他饿了，他打算以后想怎么吃，又怕都吃不了，才问的该吃哪一个。
……要是需求都没搞清也强行算饿了，那还是饿死吧。
这里提其它的，都是看出一开始饿了就是有问题的。半饿不饿都没自信石锤，是不是能消化也有问题，吃哪个在这里就是 XY 问题。
吃别的或者种地都是给确定饿了能指望吃饱的参考的，告诉你就算真饿了，这些口味都不怎么样，自己看着办。
要是实际上根本不饿，种地不种地都医不好幻觉。

这里的问题“和学具体语言其实没有直接关系”和“语言就是个工具不对”都是人间常识。
哪路神仙有本事彻底不让语言影响自己的心智？这种会饿才怪了。我是没见过；凡是如此自称的，三两句就把心智包袱抖出来了，所以我愈发不信了。你看起来不同意这个常识？那么你是觉得自己天神下凡呢，还是传教搅混市场有钱赚？

@ZXCDFGTYU 不建议 C 入门的首要原因不是因为 C 本身的问题（虽然绝对不小），而是因为这几十年来学 C 在现实中极其容易引起不学无术的用户觉得自己功德圆满的错觉。
不是特意跟你个人经历过不去，实际情况就是绝大多数自认为所谓学会 C 的用户，学的特么压根就不是 C，而是某些劣质材料作者以讹传讹脑补出来实用起来一无是处的缝合怪。（……先不管严格意义上的 C 学正经了基本也不可能有什么实用性。）
随便举个例子，这里就见到过不止一个一口一个“C 没有对象”的同学，殊不知实际上对象(object) 就是 C 的基础概念（几乎没有之一；作为名词的“变量”反倒不是 C 的内容），说出这种话的还说自己学会 C 的你能让人信？这样三人成虎惯了，能指望市场上有多少学的靠谱的？
结果就是不去管学会，光是试着去学来放纵恶劣的学习习惯，已经是在互相伤害了。所以光是照顾培养学习习惯，首先就要确定有基本的鉴别材料质量的能力和自觉，才能考虑碰这种遍地坑货。

某乎那个问题没到点，重点就是 @secondwtq 提的：最开始的 bootstrap 不要求编译。

@Cu635 @qinliming
汇编显然不是机器码，否则就没汇编器什么事了。
严格意义上讲，编译器是允许以批处理形式执行的把源程序翻译成目标程序的翻译器，而汇编器是一种简化的编译器。现代的不少编译器工具链直接包含汇编器作为其中的一个组件。
只不过历史上提出编译器概念的时候着重强调和机器无关，而当时的汇编普遍都是依赖机器的，所以在讨论高级语言的编译器时汇编器就往往被隐含排除了。

@hehheh Python 还真有编译，.pyc 就是编译出来的东西，只不过编译出的目标代码是中间的字节码而不是体系结构相关的本机代码而已。
注意编译器不一定要求输出可执行程序。而且，你现在在宿主语言实现看到的编译器也好单独汇编器也好，其实都是以编译器驱动(driver) 去调用链接器输出的，单独的不管是高级语言的翻译还是低级的汇编步骤都只生成包含目标代码的对象文件(object file) 而不是可执行程序。而排除编译器驱动和链接器的工具链仍然能叫编译器。

@ac2sherry 预处理记号、伪指令、宏以及其它注记这些可选的部分都可以不对应目标代码。
实际上，汇编语言也不一定需要是和机器相关的低级语言。用汇编器的形式实现高级汇编语言完全没有理论问题，只是大部分汇编语言都是硬件和个别适配具体体系结构的汇编器厂商提供的，很少有人这样设计而已——为什么放着高级语言的通用翻译技术而要纠结按传统汇编器那样使用助记符引导宏展开去实现一个编译器呢？

@ZXCDFGTYU 对了……鉴于你建议小孩子从 C 入门……我据此非常怀疑你的 C 没学到入门的程度，要么压根就没学别的……

@ZXCDFGTYU 功利教育噶韭菜忽悠投资嘛，愿打愿挨，都懂的。

不过某种意义上这里的教学内容还真可以是严肃的编程。为什么现在多数情况下习惯把这样的活动不视为编程，反省的其实该是大多数其他业内人士。更一般的看法是依赖业界的整体风俗的：
http://tunes.org/papers/WhyNewOS/WhyNewOS.html#htoc16

另外，计算机相关行业里的配得上叫科学的，恐怕真没多少内容……

这啥煋……这人的视频 up 主是家长，之前已经在评论区交流过了。
爱好跟职业是两回事。就现在大多数人的眼界，基本上不要指望去靠“教”学会点什么名堂出来。