@pizida 如果是全新内容， rsync 没有优势，但如果是增量同步， rsync 可以大大减少带宽。

rsync ？

Paxos 的扩展性有问题吧，只适合比较小规模的集群间同步。

从原理上来说，空调效率最高（最省电，同时取暖最快速）——然而空调有噪音。

无噪音的设备来说，地暖是全局最优，石英灯、电热毯等是局部最优，其他选择介于两者直接。

@fishioon 理解你们的业务，很多时候设计再好的架构不如一个 DBA 。

@kikyous python 的 str 是 immutable 的，相连是需要复制整个数据结构的。

@wy315700 并发问题绝大多数出现在 IO 相关层。当然，如果是由代码上非线程安全而引起的，就是制造不合格，和设计无关了。

@mzer0

"想必你也不懂什么叫消息队列 /缓存 /高并发"——我劝你少评价别人，戾气太重，学鸠摩智没有好下场的。


PHP 、 Python 之类的，有 GIL ，当然有并发瓶颈，我一个不弄 python 、 php 也不弄 java 的都知道，翻译都没翻译过来，怎么去并发执行的道理，一个弄 python 的会不懂这个吗？

你弄过个线程锁，理解过其中的复杂性，就了不起了，以为所有人都不懂了？会个 go 了不起了，知道 goroutine （学术名字应该叫做 CSP ）怎么实现就出来卖弄了，也不看看人家 erlang （你眼中的脚本语言）单机单线程时代就做到多少并发了？——没错，这里面非常复杂，但自己去对付就是巨大的成本， CTO 傻到看不到成本就去追求性能，这样的公司才药丸。

弄 python 的线程锁方面可能没你懂，但人家去做 CTO ，一定比你这个只看并发性能的更成功。

这本书翻过英文版的，似乎是个微内核实现。

debian KDE 多年（ KDE3 时代开始的）。

@zjb861107 没错，商业运营比技术重要多得多。

@mzer0 看到这样大段大段地用“！”就来气。

“让服务器的 cpu 真正跑到 100%的占用率”本身就是一个错误的方向。

架构上第一重要的是业务绝对安全，第二是开发成本和维护成本，第三是运营成本，第四是扩展性。性能什么的优先级非常地低。

真的重要了，也是因为性能不好导致运营成本大于改进性能的维护成本了。

一个弄 Java 的不一定比弄 C#， python 的更会考虑上述这些。

没有很多，只有一条，试探性的回复后发现是群发。

没诚意，没节操。

目前已经在 Kerbin 轨道有 12 颗卫星， 1 个空间站， Mun 轨道一个空间站， Mun 和 Minmus 均登陆，各有两个卫星，但还是没有飞出 Kerbin 系统。

对接飞船的，可以用一个 Docking Port Alignment Indicator 的 mod ，可以显示当前飞船的 port 和目标 port 的相对速度，相对偏移，相对距离。

虽然我是宁波的，但忍不住还是来吐嘈下：“精通浏览器兼容性问题的解决”的都不是好前端，好前端怎么只有这点追求，至少要弄得起 LESS 啊， AngularJS 啊， ReactJS 啊之类的

@teek 这样说就有些偏颇了，就像说：“乔布斯貌似也不看西医，据说西医没有治好过肿瘤”。

外键不会保证数据不损失，但是外键可以保证数据不会因为人为的“缺陷”而损失。这种“缺陷”，往往在逻辑稍微复杂一点的环境下非常容易发生。

函数太长，差评！

95+%的开源软件是自由软件。

而应该是 100%才好。