前两年的时候我还去看过这张画，个人感觉更偏向冷色调。
http://www.marmottan.com/francais/collections-musee/claude-monet.asp
这是博物馆的页面，最下方的图片放大看比较清晰。因为时间比较久了，加上馆里灯光偏暖，我印象里的实物比图片上更红润一些。

莫奈除了这张《日出》，还有一幅同主题的 Sunrise, Marine，通过搜索可以看到，这张图基本都是冷色调，所以那一张是冷色调的可能性更大一些。Sunrise 系列描绘的是晨雾里的海港，我记得当时看多数色彩都是与灰色颜料混合而成的，所以整副画面给人感觉是偏灰的，映衬出橙红色的太阳感觉很和谐。

我听到过一个说法是，油画时间长了会褪色，而根据莫奈其他的作品来推测，原作可能用色更鲜明，所以才会有偏绿色的复原图。

有可能是 earth 2150 么

莫非是 westwood 出品的 Dune 2000 啊？

@cyfdecyf
这个问题我没法回答，想知道是否调用 SMJobBless 只能通过逆向手段来确认。另外，调用 SMJobBless 还不够，重要的是通过 code sign 方式实现主程序和 helper 的信任关系。
但是，可以认为 ccc 3.5 版本依旧存在此漏洞，原因是代码签名会在 Info.plist 中留下 SM 相关条目，而 ccc 3.5 的配置文件中找不到相关的信息。

@cyberscorpio
我前面那个回复本意是尽量简洁地描述回答，也故意隐藏细节，因为这个问题实在过于复杂。另外 adobe/apple 以及 flash/osx 毕竟都是私有产品，我的理解也可能有误，这里我把我的理解阐述一下。


所谓的硬件加速具体指什么，win/osx 硬件加速支持如何？

两个方面： H.264 解码硬件加速，屏幕渲染硬件加速。
H.264 是高清流媒体的半事实标准，高压缩比可以大幅降低网络带宽需求，代价是解码运算量大。（其他编码方式由于解码运算量小，从硬件加速中受益不明显，所以通常特指 H.264）
win 环境通常由显卡厂商随驱动提供解码器，可供 flash 和其他播放器调用。
osx 目前 Lion 版本未提供 H.264 硬件解码接口（QuickTime 可以调用私有 API 实现硬件解码）。
目前网络视频流最流行的封装手段依旧是 flash 播放器，flash@osx 的性能问题主要就是缺乏硬件解码支持造成的。
后者是现在主流操作系统图形框架的基础（compositing/hardware overlay）。这方面对于性能的影响主要是 flash 动画，不如前者明显和广泛。
compositing/overlay 的优点在于，应用程序独享自身界面部分的显存，组合渲染由显卡硬件实现，图形界面渲染对于 cpu 的占用大幅降低，同时可以利用显卡实现大量窗口特效。
02 年 Jaguar 就实现了 compositing 硬件加速（基于 opengl），06 年 vista 也转向了组合机制。08 年 flash v10 开始支持 win 硬件渲染，10 年 flash v10.1 支持 osx 硬件渲染。


flash@win 和 flash@osx 到底有什么不同？

flash 本身没有太大区别，不同在于 win/osx 的设计思想，windows 强调兼容，而 osx 硬件平台相关的，这样的区别决定了 win/osx 对于第三方 runtime 的不同态度。
win: Hardware -> OS -> OS API / 3rd runtime -> Software
osx: Hardware -> OS -> OS API -> 3rd runtime / Software
flash 作为 3rd runtime 在两个平台的地位是不同的，一般来说，越接近硬件越会有好的性能。出于兼容性考虑，win 向软件开放大量硬件细节；而 osx 只允许第三方应用调用高级 API 同时隐藏硬件细节，保证了上层应用的统一性。flash 在两个平台上的性能就有了先天性差距。


一句话总结：flash@osx 性能差的原因主要是缺少 H.264 硬件解码支持，小部分原因是图形渲染流程所致。


------------------
至于产品的问题，类比汽车产业的更新换代，adobe 在核心产品上的做为不说优秀，也可以算作中规中矩。这也只是我的看法而已。

楼主疑惑的应该是两个不同但相关的问题：
一是为什么 flash@osx 会使 cpu 明显发热，但 flash@win 为什么就不那么热；
二是同样是高 cpu 负荷的解压缩工作为什么就不热。

先解释下问题三：
core i 系列 cpu 有一项叫做 Turbo Boost 的单核心加速技术，可以依据功率和散热情况短时间提高单一核心的运行频率，加速时的功耗要高于无加速情况下多核心满载的功耗。
flash 是单核心依赖严重的应用，而虚拟机和解压缩可以充分利用多核心。前者会触发加速，因而实际 cpu 功耗和发热要超过后者。

至于 flash 的运行效率问题，只能说 @win 比 @osx 确实要好得多，这与两个系统的图形渲染架构有关。绝大多数 flash 以绘图工作为主，win 版本的 flash 解释器更接近图形渲染后端，而苹果出于安全以及全局考量，拒绝 flash 解释器介入图形渲染的流程，使得 flash 渲染需要走前级图形接口，效率上自然有差距。
这也是 adobe 抨击苹果不合作的地方。osx 的硬件加速长期落后于 windows 也是类似的结果。

PS
作为一种跨平台解决方案，flash 和 java 一样，不得不向效率作出妥协。而在 v9 引入 JIT 技术之后，除了寻求深度系统集成和硬件级加速，flash 已经没有再度提高运行效率的手段了。
至于 adobe 不思进取，看看 adobe 家其他产品吧，至于说 flash 优化不好，我想，有能力优化 的情况下，adobe 会看着 flash 从 90% 的市场份额一路狂跌而无动于衷？假如现在的 cpu 能够集成几十上百倍的矢量运算单元，可能 flash 会是一种人见人爱的技术。

PPS
现在 flash 唯一的阵地就是网页内嵌视频领域了，而且一直有 HTML5 video 取代 flash 的呼声。实际上二者的解码部分是一样的，区别在于，flash 不具有渲染到显卡的能力，而浏览器也没有办法介入 flash 内部，基于 flash 的视频播放必然会受图形系统的影响，而调用硬件加速在沙盒化环境中又是处处受限，前景确实惨淡。基于原生 HTML 支持的视频播放，更容易被浏览器优化，调用硬件加速也更加方便。
所以说 flash 不是死在闭门造车不思进取上，而是死在了更先进的技术面前。我丝毫不怀疑，在运算能力大幅度提升的未来，基于虚拟机的跨平台方案还会卷土重来。

这个与地区有关，看当地的金属冶炼情况。
欧洲的易拉罐是顶盖全铝，罐体是铝钢合金，可能国内的也改了，美国的应该还是全铝的。
铝仍旧是主要的金属，虽然合金不容易回收重炼，但易拉罐上盖还是没能变成铁盖，主要是因为钢质切口部分不耐腐蚀。
易拉罐由铁铝变成铁这个说法有些不太靠谱，不过罐头基本上都是纯铁的了（马口铁）。
我猜测纯铁罐没能取代铝铁合金的原因还有重量，铝铁能够做得更薄更轻。

@kokdemo
主要是你现在这个设计看不到核心规则在哪里，比如兵种单位基础数值，以及所有手牌，这些基础设定的重要，在于你可以推算对应的波动范围，并以此来确定获胜条件。没有完善的数值和规则做保证，大局观策略什么的根本没有意义。

一般游戏获胜条件都是围绕一种或者几种资源来设定，这种资源通常是有限的，比如手牌，或者是地图占领，甚至是抽象的，比如 euro game 中常见的得分。

我又看了一下前面的设计，印象中 bgg 有讨论地图拓扑和数值设计的讨论，而且现在流行的桌游模式也有总结，可以借鉴一下。对于这种网格拓扑来说，增加斜线逻辑能很大程度上提高变化可能。

另外我自己从来没做过这么大型的游戏设计，元素太多就慢慢驾驭不了了，简单的游戏逻辑难以拓展，这是我真实的感受。

@kokdemo
主要是你现在这个设计看不到核心规则在哪里，比如兵种单位基础数值，以及所有手牌，这些基础设定的重要，在于你可以推算对应的波动范围，并以此来确定获胜条件。没有完善的数值和规则做保证，大局观策略什么的根本没有意义。

一般游戏获胜条件都是围绕一种或者几种资源来设定，这种资源通常是有限的，比如手牌，或者是地图占领，甚至是抽象的，比如 euro game 中常见的得分。

我又看了一下前面的设计，印象中 bgg 有讨论地图拓扑和数值设计的讨论，而且现在流行的桌游模式也有总结，可以借鉴一下。对于这种网格拓扑来说，增加斜线逻辑能很大程度上提高变化可能。

另外我自己从来没做过这么大型的游戏设计，元素太多就慢慢驾驭不了了，简单的游戏逻辑难以拓展，这是我真实的感受。

作为一个桌游爱好者看到这帖子很兴奋~
我大概玩过 100 种左右的桌游吧，包括卡牌类和桌面类的，绝大多数只是玩过一把了解下规则，真正常玩的是策略对抗和娱乐休闲类，感觉在十种之内吧，很少玩剧情向的 dnd 跑团，主要是团长不好找……我也尝试过设计桌游，不过没有什么作品，随便说下我的看法吧。

关于你的设计：
1、卡牌和棋盘的结合，这个是很多桌游的设计思路，我倾向于认为，纯卡牌为一类，需要其他辅助道具的算另一类，通常后者要比前者复杂。
2、即使战略，对于桌游来说，没有真正意义上的“即时”，同步回合制（指令独立，结果同步）比轮流回合制更接近即时的概念。当然你这里描述的即时战略更接近“多单位制衡”和“采集生产战斗”的意思。
3、竞技性平衡性随机性，随机性和竞技性几乎是对立的两个极端，多数情况下随机性越强的桌游，竞技性就越差，更多的是娱乐向设计。

一些可能有启发的桌游设计：
Starcraft:The Board Game 我玩得相当多的一套，也是最接近你描述设想的即时战略对抗性桌游，也是我认为 ameritrash 里面最好玩的。不过复杂度应该远超你的设计。
Neuroshima Hex 这个很接近你设计的规则，而且有着比较好的竞技性和随机性平衡，不过随机性还是左右输赢的明显因素。
剩下的没有太像的，或者因为我玩得太少，说下亮点：
Through the Ages:A Story of Civilization 科技树
Twilight Struggle 大棋盘
Power Grid 资源采集与数值设计

我在试着设计桌游的时候想到的问题：
1、核心规则，到底是以随机性为核心的娱乐向，还是以精细的数值设计保证对抗性？前者更容易设计，后者的难度在于，核心逻辑要经得起考验，很少见到有什么理论，一款好游戏几乎都是在反复试错的过程中改进来的。
2、人数时长学习曲线等等，通常复杂到一定程度的游戏一局都要几个小时，或者每局只要半个小时，但是第一次要学习很久规则，但是过于复杂的规则会使游戏很难推广。
3、背景设定，一般来说都是先有规则，背景什么的就像皮肤包装，怎么套都可以的事情，但是实际设计的过程往往是先想好个背景，然后把规则往上套，这是比较难的地方。
4、一定要反复试玩，这是个很蛋疼的过程，至少我自己设计的规则经常玩几把就找到 bug 了，而且是根源性的很难解决。看别人的设计也经常是这个结果。
5、如果要添加指示器/骰子等等辅助工具，就不要想着简化了，成功的桌游几乎都是前面两个分类的极端，极简单或者极复杂。涉及到数值系统的也是一样。
6、有事件系统的卡牌桌游大部分是用事件来平衡随机性和数值系统的 bug 的，我是这么理解的，事件是个非常好用的打补丁工具。
7、针对你说的开源，这种情况下核心是规则，真想玩的玩家不会被制作的困难所阻碍，但只想试试的玩家看到制作太复杂很容易打退堂鼓。但你这个设计又是明显的复杂向，甚至要借助模型/指示器/骰子，几乎没有开源的意义。

大致说下我的理解，这是一个上亿的 kv 数据库，写入远大于查找，有明显访问热点，以及需要数据持久化的情形。目前的问题有两个，内存不够，性能不够好（第二条不知道是不是有需要）。

在架构不做改动的情况下，加内存是最好的办法。看前面的说明没有提到集群，如果是单点服务器的话，32GB 内存大概能支持 10^8 kv 吧，不过 32GB 确实是很多小型服务器支持的内存上限，如果是硬件的限制那就没办法了。

数据持久化方面，我觉得传统数据库不如 redis 方案，而且每天一次 dump 保存到 ssd 已经是很好的办法了。性能方面，因为只有共享写入才会产生瓶颈，假如热点数据并发写入较多，还是分离出去比较好，其他地方应该不会存在瓶颈，有也是硬件级别的。

如果未来数据规模不会增长太多，硬件升级成本比软件架构更新的维护管理成品应该是少的，如果数据规模还会进一步扩大，转向集群应该是必然的。

hardcore 玩家其实都在玩 simcity4 呢，十年以上的游戏群体不止 diablo 玩家。
关键在于那个引擎上面，mod 代码非常容易写，只是要到 2013 才能见到……
目前看起来多人游戏的意思是，你再也不能把垃圾卖给邻居了 =,=
按照 EA 的尿性，全程在线 DRM 是没跑了，还好是 Maxis 制作，其实我一直想吐槽的是，十年了，还没有哪个城市模拟类的游戏支持利用 cpu 多核心，十年了！

http://community.simtropolis.com/forum/83-simcity-2013-general-discussion/
这里是模拟粉丝的归宿

300*100/10=3000 字每小时

Bootstrap 2 可以考虑一下

那个键盘是以复合设备的形式实现 usb 全键盘无冲突，mac 对复合设备支持不好，换别的产品吧。

我刚好在尝试这么用

@Ricepig
你说得很对，我本来是想说 cpu 相对于 gpu 运算能力是数量级的差别，在分析这个问题的时候就像数学上说的低阶无穷小，可以被忽略。
不过 flops 确实不太适合用来简化评价 cpu/gpu 的性能差别，不过现在硬件厂商普遍标注的是等效 x86 flops 效能。

这是因为 cpu/gpu 是两种不同的架构，针对每个时钟周期而言（per clock）：
core i7 920 每个物理核心可以通过 AVX-256bit 执行 4 次 32bit 浮点指令
AMD 6970 通过 1536 shader 单元可以执行 1536 次 32bit 浮点指令
考虑到时钟频率：
core i7 920 @ 2.66GHz x 4 cores
AMD 6970 @ 880MHz

这样 AMD 6970 GPU 相对于 core i7 920 大概是 32 倍左右。
core i7 920 @ 0.1Tflops / AMD 6970 @ 2.7Tflops 基本表明了这一点。

/etc/init.d/sshd start
如果能够启动说明是 selinux 策略问题。
如果 selinux 工作在 enforcing 模式，service 需要命令行参数读取启动脚本，这个脚本可能不在策略集的允许范围之内。