@21grams 第一反应我也觉得他是在说反话，尤其还带了个（逃）结尾，但问题是第一个回复真的很挑战我的语文阅读能力，也许是真的退化了吧

@wwqgtxx 那你解释一下这句话什么意思 [解决上面两者的办法就是服务器提供更多的公开 IP 地址] ，自己不觉得可笑吗，这是最后一次回复

@wwqgtxx #78 你这是对 tcp 服务的理解是完全错误的，实质和贴图内的观点是完全一样的，请不要误导别人

为什么不看文档 https://nodejs.org/api/fs.html#fs_fs_readdirsync_path_options

@wwqgtxx 不知道是我语文能力问题还是你理解能力问题。我的意思是说 tcp 端口数不会成为单服务器连接数（也就是 c100k 问题）的瓶颈，因为在 tcp 层面，一个 ip 一个物理机和一个 ip 多个物理机或者虚拟机在客户端看来是完全没有区别的，不是说这种方式能提高服务器的并发能力，后面的是反问句式，说明假如 64k 问题存在的话，单 ip 负载就存在瓶颈，从而导出一个明显是错误的结论

@shoaly 源和目标是相对的，在客户端看来的“源”在服务端看来就是“目标”了啊

JavaFX 请看 => https://youtrack.jetbrains.com/issue/RUBY-18230

需要 10 进制浮点运算的请使用 BigDecimal

不要听 30 楼推荐，要学习好歹也去外设天下啊

无法接受老 MBP 键盘

还是多此一举解释一下吧
65k 端口数限制的前提是源 ip, 源端口, 目标 ip, 目标端口这四个变量固定前三个变量之后才有的

c100k 问题固定的变量只有前 2 个，所以加上目标 ip 这个变量，理论连接数可以有无数多个，也就是说，如果一个 IP 后面可以堆一堆机器的话，是可以有远超百万级这个数量的连接的

如果不信的话，你去 dig 一下 12306.com 看一下这个域名绑了多少个 ip ，假设是 100 ，然后就可以得出 12360 只能服务最多六百万用户的可笑结论了

至于截图的内容，说实在我还是有点惊讶的，其它就没啥可说的了

命令行挺好的
需要友好一下的浏览视图的话，可以用任意 JetBrains 产品的 svn 插件里面的 Browse VCS Repositories 功能

mkdir tmp && cd tmp
git init
git fetch <你的原项目地址> <你的子项目分支>
git push <你的新项目地址> FETCH_HEAD:master

这 sb 问题和下结论说 256-bit AES 加密破解复杂度只有 o(n) 有啥区别
反正你喜欢定义 n=2^256 就好，反正这个数也没多大，一个宇宙也没多大呗

多看了一眼
哦
原来是 windows

这命令又不会删除任何实质性东西的，仅仅是修改了 index
reset 不就回来了吗

generic / covariant / invariant

这几个概念建议都要看一下

早期的 java 没有泛型，但有数组，而数组在 java 语言里面是定义为 covariant 的，也就是赋值相容的，这其实是一个错误，因为把一个 String[] 类型转换为 Object[] 没有任何警告，但以后的元素赋值可能会产生 ClassCastException

Java 泛型的设计纠正了这个错误，是 invariant 的，也就是赋值不相容，你不能把 List<String> 直接当成 List<Object> 来用，但可以当做 List<? extends Object> 来用，自然而然， extends 和 super 关键字就是必须的了

invariant 的泛型也给编程带来很多麻烦，因为无法进行类型转换（当然，因为 java 的泛型是擦除的，强制转换并且消除警告也总是有办法做到的）

进一步的，如果你有看过 kotlin 的话，有专门章节介绍泛型， kotin 用 in / out 标记来代替了 extends / super ， in / out 关键字不仅仅能修饰泛型参数类型，还能用来修饰泛型参数声明，配合不可变集合类型就能够支持 convariant 泛型（赋值相容）

比如 kotlin 的 List 是不可变的，其接口声明是 interface List<out E>;
意思是只能从里面取出来 E 类型的元素，不能保存
那么 List<String> 和 List<Object> 就变得赋值相容了

长连接的首要前提数据协议必须可分段，而且你得知道协议分段的细节，怎么可能有通用方案