港版从来都只有英式插头，至于英式是什么形状你可以搜索

浏览器读文件，你是在逗我们？

@xiqingongzi 因为我最近也在找合适的 CI 工具，所以就多看了下，其实你的需求，直接用 CI 似乎比 WebHook 更合理呢

@xiqingongzi 看来我第一个回复没说错，这个贴图不是已经很清楚了吗，是 push / merge (push) request 的 hook 而不是针对 commit 的 hook, 概念不同的

@xiqingongzi 不是这个意思啊，不知道是不是我理解不对， commit hook 是 local 的啊并不能分发，协作层面的 hook 只能是针对 push 或 merge request 这类操作吧，而且一般都无法 pre hook 只能是 tigger ；当然 trigger 也可以做到比如自动 reject merge request 之类的

@enenaaa 所以我说需要一个清楚的定义啊，然后讨论才有基础，在操作系统层面的同时那就是针对 CPU cycle ，在网络层面的话，那就复杂多了，只要是共享介质的，都不可能有真正的同时

@enenaaa 说概念首先得有个标准，同时的标准应该是指多个 CPU 核心可以一起处理不阻塞，在这个概念的前提下， linux 的 tcp 协议堆栈的实现应该不满足这个条件。所以 @jsou 是对的。

意思是说，服务端的一个 ip:port 是共享同一组缓冲区的，也就是两组应用如果是服务同一个服务端口的话，就不能真正的同时处理，只能分时并发处理，至少在从缓冲区获取以及写入数据这个行为上是互斥的。

当然，是否有其它内核能支持真正的同时，我就不清楚了

> 登录 Github/Coding,在项目设置中的新增一个 GitHook
这应该是 webhook 吧

> 提交 git commit ,GitHook 会自动执行你在 config.json 中设置的命令
你是否混淆了 commit hook 和 push hook / push request (merge request) hook 的概念？

@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 只能服务最多六百万用户的可笑结论了

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