ineligible devices +1。最后在爆栈上找了个临时绕过方案，直接在Product菜单Destination里选。

。。。按这个测试结果，这个观察角度可不算最简单。更简单的角度是……180开头这个服务器对全世界返回的结果都是攻击github的，58开头这个对全世界都不是。

前两天攻击那阵，你访问被借刀杀的那两个URI直接返回的就是alert，根本不管是否正常访问。现在还是独角兽状态。

……你觉得哪里解释不通呢？我也看不出啥问题。

@FrankFang128 换了zprezto，还是卡。。。不过我得说比在bash下用powerline已经强多了。

这个要看你用的是哪一次的越狱。不同的越狱方法，默认留出的空子是不一样大的。
举例说（下面的我都不会指名，清者自清），有的越狱会关闭ASLR或者MAC；后续攻击就容易多了，甚至通过苹果商店分发的应用也未必能信任了。有的越狱会直接允许未签名代码运行——甚至不用用户自己去装appsync，知道wirelucker攻击原理的应该知道这意味着什么——没有0day也能为所欲为。有的越狱会默认开启afc2，等于声明整个根文件系统可不经机主允许任意读写，这个更不用说。
如果你本人没能力分析越狱方法和后果，至少自己常用的机器上切忌一有可用越狱就用，请等待社区检验安全后再说，尤其是肌肉男/pod2g/comex的。

等它的SSD出来记得自觉来被MB的NVMe SSD扇脸。

这两天刚碰到一个问题：有坚持10.9的同事，提交到itunes connect的build在processing阶段呆了一天多也没下文，卡死在那了。我上网查了一下发现甚至有两个星期也过不去的。于是在自己的10.10机器上编译，提交……10分钟后搞定。
供参考。

@garfeildma 同出而异名罢了。late binding着重在绑定时间上，duck typing则着重强调忽略类型调用的能力，在讨论语言表达能力时后者更切题一点——虽然说的的确是同一个概念。

@damngood objc里有能力给任意object发任意message……这比一般意义上的duck typing都要强。http://en.wikipedia.org/wiki/Duck_typing#In_Objective-C
静态强类型是有上面列举的好处，这点应该承认，但得到这些好处并非没有代价。它本身是会极大阻碍语言自身的表达力的。举个最简单的例子，纯swift里——跟C++一样——连json字面量都写不出来。所有swift的json库，你可以看看是否有不基于ObjC的NSDictionary做出来的。参数化类型(C++模板/swift范型)为此能做的不多，但是拖慢编译时间有余。而语言的表达力和编译速度是快速迭代的基石。这基本上可以解释C++为什么在今天不再是主流前端语言，而我看不出为什么swift会例外。
注：我本人没在用swift做开发，仅就了解到的情况评论，听者自辩。以上仅就当前swift与objc泾渭分明的情况立论，未来可能swift和objc会从语言层面进一步融合，我个人认为只有那样它才有替代objc的可能。

swift走的是C++的老路：静态类型，模板化参数，编译期绑定。即使实现了增量式编译，我也不看好它的编译速度能有多快。
苹果的系统一直是用动态语言构建的，想一步登天改成swift这样一个静态语言，结果就是以前鸭子类型遮住的bug一下子全都暴露出来了。现在仅限于xcode都这么能死，我不敢想象苹果一旦决定用swift改写系统组件会是什么级别的地震。

小米路由技术坑。极路由人坑。

说起来一加之前貌似也有人说碰到这个回落问题，不过个人没啥感觉——本地八线小城市信号本来就是得喂喂若干次进行人工握手的。理论上现在移动4G应该都有。

观察完毕，已block。

@shadyxu 看这个用户名像是戏仿。

@aruisi 个人体验正如你所说。给你个截图： http://postimg.org/image/7rkxadqgj/
日常使用上占用内存高的只有chrome+xcode，之前用firefox，但最近网络不稳定，只要一断网firefox占内存就往上竲竲竲飙，最高观察到过12G，已经没法用了。