自己的代码的部分，不声明的话默认保留所有权利，也没啥问题啊。似乎也不和 MIT 及 BSD 协议冲突。

基本上，App Store 是和网页一样，服务器端用类似 HTML 的标记语言来表述内容，在客户端用类似浏览器的组件来展示内容的。不涉及新展示方式的话，Apple 可以可以随意在服务器端直接更新内容。

我公司的 MBP 是右边的 USB 口接 bub（不带电源的那种）的话就没法认出键盘，左边的是得先直接接一下键盘，然后再换用 hub 接，才能识别……

牌子的话，我倒也没什么可以特别推荐的，一般来说，听说过名字的大厂出的、稍微贵一些的，可以试试

换个 USB 口试试，不行的话换个 Hub 再试试。

@zhulong922 老版本的 MBP 有红外感应器，可以用这个来遥控 iTunes 和调节音量的。

Apple Remote，在苹果的实体店和网上商城都直接可以买到的吧。

通过它们安装的应用可能会被修改。比如我可以下载一个应用，修改后用我的企业分发账号的开发者证书重新签名，然后你只要信任我的证书，就能成功装上（非企业分发账号其实也可以这么干，只是需要预先添加目标机器的 UDID，且有数量限制）
然后如果你的设备没越狱，那么应该还好，这个应用里的数据有可能会被监听或篡改，然后可能它里面会用一些私有的 API，苹果对这些 API 并没有很认真地作过安全评估（因为毕竟 App Store 上的应用理论上都不能用它们），所有没准会有些能取到什么隐私信息、或者引起系统不稳定的；如果你的设备越狱了，那么自求多福吧……

1024 以内的端口号都是要注册/保留给已知协议用的吧，所以随机的端口号才都会选后面的。

至于为什么要随机，而不是指定一个端口让所有客户端来连，就不清楚了。可能是怕麻烦？

@FrankHB 既然“UTF-8字节序统一”，那还要 byte order mark 作甚。

你的 putty 是哪来的……不会是误下了以前出现过的被修改过会偷密码的那些版本了吧……

使用微信的 iOS 客户端的用户数量必然比有 Apple ID 的 iOS 用户数量少，所以这种负载对苹果来说是完全可以预见并且应该可以正常支持的。

并且苹果在开发者文档里面也明确说了，推送不保证及时，也不保证一定能到，如果应用有这方面的需求的话，得自己想其它办法（不过基本没啥其它办法，目前对后台任务的限制少了，但是性能方面的限制还是有，并且用户也可能会去把应用的后台权限给禁用掉）。

话说，Google 的各种语言的代码规范里面，大都会提到旧代码如果不符合规范该怎么办，其中一个很重要的原则就是不要*仅仅*去为了让代码符合规范而去改。

所以在我看来这要求的确有点神经病了…

没啥特别省事的方法了，也就是修改-单元测试如此循环，该多少工作量就上报多少工作量吧。如果有什么来不及，那责任肯定不在开发这边。

我这边什么也没看到，莫非是 flash？

日语的罗马音转写也是有很多方案的啊。实际用起来还是看各人喜好。甚至连护照里面要求的拉丁化名字，日本政府也只是给了推荐方案，但没有强制（这点香港应该也是如此吧）。

比如 Ruby 语言的作者，松本行弘，其姓「松本」，可以写成“matumoto”，也可以写成“matsumoto”，后一种对于外国人来说似乎会读成更接近日文发音的样子。

然后日本人把姓名拉丁化的时候，似乎大都按西洋的惯例，把姓放到后面，于是上面例子里的「松本行弘」，一般会写成「Yukihiro Matsumoto」。

但是，他本人选择的昵称是取了其姓的一部分而来的「Matz」……（在我看来，这个在外国人读来倒是更接近日语里面松（まつ）的真实发音了）

404

另外按相关 RFC 里面的说法，user agent（浏览器、搜索引擎、代理服务器）必须把 404 当成一个临时状态。

@c4pt0r 这个反了吧。systemd 也只能算是勉强追上了 launchd 而已。