整本 Physically-based Rendering 需要的知识不会超过研究生基础课，可能通信本科生基础课就够了（如果要理解采样的一些概念）。

Code review 是为了保证你的 code 不会违反一些原则（比如 single source of truth, don't repeat yourself ）。这样以后发现问题更好处理。而不是保证没有 bug。

Value type 的 life cycle 不能统一由 GC 控制，语法必然复杂化。

这种就是典型的 high energy 傻逼。我们 team 和一个这样的斗争了三年多。最后他去祸害 Future Wei 去了。

我从十年前 Swing 和 Flash 的经验就反对 non-native UI kit。后来在美国这边不得不帮助维护了一个 self-render UI kit （类似 Flutter ）。两年之后，除了一个力主推这个方案的人，其余所有同事基本同意这是个垃圾。

@quietjosen 你觉得 macOS 的沙盒需要怎么变呢？我觉得有了 sandbox 就可以了。就像服务器的安全其实用 9-bit 都能够用了。

不同的 remote 不是用来区分不同的内容的。因为 Git 区分不同内容的唯一方式就是 SHA-1。所以还是老老实实的 branching 才对。对 Git 来说，不同的物理位置根本不是区分内容的依据。

@chchwy https://www.turbosquid.com

@ideacco 是「写」的啊。当然模型不是我写的。

我上大学的时候也天天烦恼要选的「方向」。现在看来这些都不配叫「方向」。

今天偶然看到这个，@monnad 说的是我的答案，所以我觉得虽然日久挖坟，也要澄清一下。

第一，我非常反对说「不是专业的法律人士」就不能谈法律。法律本来就是让大众理解的，难不成大家平时混日子，打官司的时候再撞大运看自己的行为合法与否？

接下来说这个例子：「如果 Sun 把 GCC 移植到 Solaris 上，也不会感染 Solaris 。必须证明你的系统是 GPL 软件的潜在目标平台。」 @monnad 说例子很有误导性，其实 FSF 自己解释 system exception 的时候用的就是这个例子，只不过用的 Windows 。

@monnad 说这个例子没有共享代码，这是我没有说清楚。因为 GCC 在 Solaris 上必然要动态链接 Solaris 的 libc （而不是 glibc ）。但是 Solaris libc 却不必开源。这里没发用 address space boundary 来解释，所以必须用 system exception 来解释。

再有，@monnad 说「 GPL 中明确定义了什么是“使用”。一个网站可以用很多 GPL 的程序，但并不意味着整个网站都被 GPL 感染了。」我想我前面已经对如何「感染」写的很清楚，所以这里偷了一点懒，用了「整个网站」。但是我的意思是如果作者在没有两道边界的情况下用了 GPL ，那么在边界之内的整个部分都是 GPL 的。至于 @monnand 说「保护公司内部代码不外露的手段是保密协议，这已经是很强的法律手段了。」我并不认为这个手段比版权更强。因为这个手段只能惩罚泄密行为本身，并不能保证禁止后续的对作品的使用。

iostream 自己有同步。由 sync_with_stdio() 控制。

不允许动态库和技术没有什么关系。主要还是生态圈的问题。

Apple 不希望有第三方厂商发布在 iOS 上用的重量级 SDK（比如像 Qt 之类的）。当然你要开发也可以，但是没有动态库支持发布大型 SDK 会有很多问题，比如 symbol conflict 之类的。总之不是 blocking issue 但是算个 barrier。

安全是一个因素。也许是大家没有考虑到的一个，但是客观上起作用的因素。攻击者对你的系统了解越多，攻击手段就越多。Pre-built Installation 就那么几种，通过一些技术加 social engineer 就能搞清楚你安的是什么，缺少什么补丁。

我估计你可能只知道 breakpoint 和 step。除此之外，debugger 还可以设置 watchpoint, conditional breakpoint, 修改变量。最重要的是，每个功能都提供当时的 callstack。

讓妳的 app 進 Apple Store。會開發的下 source code 編譯，不會的從 Apple Store 花錢買。

就那个 GIL 还有用 C runtime stack 来实现 Python stack 这两点就够不上「最」。

Lua 最轻量