@guodont 哈哈这个工具在 github 上已经非常流行了。

@234747005 Rancher 是还不错的。有些比较深入的功能，完成度还不够高。

如果你在和老外讨论某个 bug 的表现能不能够“重现”，几乎说出"reproduce"人就知道你要表达的意思了，非常明确。

LZ 不要纠结了，负责任地讲，如果是在描述“产品出问题能不能重现这个问题”的意思，有且仅有的最严谨的词语就是 Reproduce ，这几乎是软件测试行业的专有术语。别管它在词典里怎么翻译的，是它是它就是它！

@caoyue
从技术角度比较悲观的估计， facebook 就是存了你的“明文”密码。

1. 针对 simhash 或者类似的算法，破解密码只需要穷举找到不断逼近的最优解就行了，遗传算法就能非常高效地解决这个问题。相似度算法，就相当于在密码序列的坐标上，给你了一块指路牌；

2. 针对“生成一堆 abc123 ”这种做法，咳咳，这与保存明文密码有多大区别……

我看你的摄像头形状感觉怪怪的……你确定是原装“Macbook”？

触摸板三只拖动没打开吧？默认这个设置是没打开的。在“偏好设置” - "触摸板"里。

用Go写的etcd，在初期是非常需要一个友好的接口与周边生态的，这利于它的发展与推广。
正因为用了http/json，无论是php/ruby/python甚至bashshell的curl wget，都能轻松地与之协作。开发人员几乎不需要阅读文档，只需要扫一眼http示例，就能够轻松的集成进去。
使用tcp/udp，就需要一整套通讯协议了，就需要各种不同语言的sdk了，就需要维护各种版本细节了……费力不讨好。

不过说回来，etcd很有可能在以后的版本中，内部通信使用纯tcp，但并不是因为带宽问题，而是延时问题。不过对外服务，http是肯定支持到底了。

P.S. 如果是存log数据，且数据规模远远超过jvm的内存大小，ES在复杂查询上的效率比较不乐观。比如，5个node，每个node 20G RAM，16core CPU的cluster，每天产生100G数据，查询7天的数据，做个简单的聚合，查询时间基本上在5s-20s，这个效率是没法拿到生产线上给客户操的。

准确地说，应该不是不存在了……默认情况下ES会非常频繁地把新数据写入硬盘并索引。你用head plugin看看ES的各个shard还有没有，是不是shard数据不完整还在recovery？

另，有没有做cluster？数据量多大？这些都会影响ES index的rebuilding。

PS， 稳定度上，一台机器跑ES还是比较靠谱的。两三台机器，最好别跑实时高负载同时indexing与searching的ES，基本上一个node崩，再加上rebalance与auto resharding，其它的node也就雪崩了。如果有个6-10台机器，差不多可以勉强感受到集群高可用特征了。
如果一天没有几百G的数据，ES压力不大，还是比较靠谱的。

其实吧。。。。。如果NMB卖两三千的话，现在差不多该和iPhone/iPad一样统治全球了。。。。所以呢。。。。咳咳。。。。差不多归根结底就是这个“价格”对应的商品达不到自己心中的期望“价值”。但重点来了：并不是每个人都会如此在意商品价格的。

所以，苹果把这玩意儿造出来了，觉得漂亮、觉得轻便、觉得可以敲敲文档、可以移动办公、可以在世界任何一个角落连上ssh，可以胜任脚本编程性质的工作，更是tmd一天不用充电！

这种“价值”对于我的体现，就是“买买买”！

管它喵的有没有USB，反正我也不用。三年前还有人抱怨RMBP没有光驱呢。五年前还有人抱怨手机触摸屏打字操作不舒服呢。十年前还有人抱怨品牌机没有软驱呢。十五年前还有人嘲笑24寸的屏幕太大了脖子扭的疼呢。

啥？性能？CPU弱？你给我个超算我也不会觉得它更快多少，我是非专业人士，我只知道网页打开够快、系统启动够快、切换窗口不卡、不会有乱七八糟的弹窗打扰、terminal和editor能够跑上两个月不崩，我就觉得爽了。就干脆把我当傻子好了，我不care这玩意儿用了什么CPU、用了什么牛逼的技术。你唯一的目的，就是按我说的要求把我哄爽了。

所以，综上所述，就是“买买买”！即使叫我傻子，说我show off，也不介意～