++这几个例子，拿任意高级语言举例都不错。就放在C里不合适……因为它就是高级语法的汇编。强调的是语句可以几乎直接对应到不长的汇编段落。
i++这种情况下，i强调的是一个内存地址，用图灵机的语言，就是一个具体可以打孔的位置。你对这一个位置强调i2=i1+1，i2跟i1是两个不同的变量……完全没有意义。
在SSA的情况下强调其是两个变量，正是因为"变量"与"地址"的解耦，让更高级的优化成为可能。但这本来就不是C，甚至C++这类语言的设计目的。如果要批判这里，C的指针设计才是更应该批判的，但这就是它的设计——和精髓：可移植汇编语言。unix hater's handbook分析的不错，这个特性让unix和C得以病毒式传播，而且方兴未艾。
关于王垠的第三题，如果要改造图灵机，维持相同的计算能力并规避地址的存在……我简单的大脑当机了若干次也没什么结果。莫非要改造成lambda演算？

@bhuztez
如果wayland仅仅依赖EGL，我还写那堆干嘛？
问题就是它不仅仅依赖vendor driver提供的上层API，反过来它的其他依赖(KMS/DRM)导致vendor driver反过来必须围绕它重写——并以GPL开源其中的相当部分。
换言之，它仅仅支持MirSpecs里提到的Free Graphics Stack。
而MirSpecs里写的很清楚，Mir要同时提供Free Graphics Stack/Closed Source Driver/Android Driver的支持——Canonical的开发能力能不能做到，那是另一回事。
这三种driver stack都能提供EGL，但后两者wayland压根不支持，这点简单google下就知道了。

讨论了半版都是politics，谈点技术原因吧——虽然到头你会发现还是politics。
wayland在可预见的未来，来自硬件厂商的支持都是基本没有指望的。在移动平台上尤甚。
主要原因是，它依赖KMS和DRM。这两个名词是现在Linux所谓open driver stack的核心。
这个stack相对于传统的厂商自己维护驱动的模型，要求暴露的实现多了很多。
如KMS本身是针对为了为了在tty和display server之间平滑切换，需要显存的direct access。于是GEM被提上日程，而为了把显存管理从显卡驱动里剥离出去，整个驱动需要针对GEM重写。
这种趋势到了极致，结果就是出现了Gallium3D。
Gallium3D可谓开放理想在显卡驱动上的极致。将所有上层API支持(OpenGL、EGL、OpenCL乃至Direct3D等等等等)都进行统一的实现。vendor需要做的只剩传统驱动模型下最微不足道的一丁点：就是把硬件特定的操作跟gallium3d提供的底层接口对接一下。而且，由于linux内核对驱动的要求(GPL)，这一丁点还必须是开源的。
这种模型真要推开，以后的GPU vendor就甭想再做任何对上层应用的优化，沦为最纯粹的计算资源提供商。可想而知nvidia/ati对这种模型会是什么反应。就算是始作俑者intel，也只是采用了GEM而对gallium3d未置一词。至于为什么，你看看ati开源驱动的性能应该就心里有数了。
至于mobile市场上的GPU对开源的兴趣——你就观察一下android上的情况好了。就连NV/ATI linux闭源驱动必须有的开源内核模块（其实就是个stub），他们都不愿意公开。结果是google只好开发了一套用户模式下的驱动模型专门用来迁就它们。
这种形式下，ubuntu想横跨手机、平板、PC、电视的愿景想通过wayland达成？难比登天。
理想可以是美好的，但现实是否愿意配合，就是另一回事了。
对坚持理想的人，我深表敬意。但我也永远不会忘记The road to hell is paved with good intentions。生在这个神奇的国度，身边的事实每天都在提醒我这一点。

LA机房，几天前丢包到过90%+。直到昨天还有10%左右，今天完全恢复。这家要说不丢包时速度是不错。不过丢包最严重的时候发ticket，答复是他们本地ping测试一点丢包都没有（给了我截图）；我在本地（联通）和hk vps ping的结果却都是丢包严重。原因是什么？恐怕只能靠猜了。

价格看起来不错。准备用什么虚拟化技术？

@ototsuyume 那是NT4.0以后的事情了。NT3.51以前整个显示子系统都是在用户态的——除了驱动。

这篇文章主题看起来主旨是给他自己以前的那篇煽动性超强的文章反动一下（反者道之动哦！），虽然有点矫枉过正，但不要被宗教战争迷住眼这点我很赞同。不过王垠到底还是被引出的一堆驳驳驳给气走了……玻璃心啊。