++这几个例子，拿任意高级语言举例都不错。就放在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的结果却都是丢包严重。原因是什么？恐怕只能靠猜了。

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