啊，竟然是这个漏洞么。当年听说之后我就禁用 2G 了。

嗯，西雅图 IP （ 255 ）我这里连接起来也是挺慢的。大部分时候阿什本的部分 IP 访问起来更顺畅，新加坡的 IP 大部分时候是访问最快的，偶尔我这里也会非常慢。

> 4.4~4.12 之间的版本，明显的能体验到感觉反应偏慢

这是修那个 spectre 系列漏洞导致的性能下降吧。你如果不是云服务端、不跑不信任的代码，可以导致禁用掉它们。

> 2.6.32 据说坚如磐石，今天和一位朋友聊天，他说好多新特性都没有，可能好多新硬件不支持，好多驱动和软件都编译不过

2.6.32 早不支持了。你要用的话你得自己修复各种 bug。你有那个能力吗？执着于不支持的版本，你就是孤军奋战了。更不用说很多新的软件无法运行（ systemd、docker 等），而使用旧版本不受支持的软件意味着更多没人修只有人尝试利用的漏洞。

毫无疑问你该用当前最新的那个 LTS。

那些旧的 LTS 存在的意义是，你的设备在几年前已经在用当时最新的 LTS 版本了。因为不同内核版本之间会有差别（特别是内核驱动啥的），本来充分测试过的版本你不用，冒然升级可能导致系统出现问题，收到大量用户投诉。当然如果你有时间和财力去测试、匹配新版内核，就放手去做吧。

@bclerdx #177 是啊。

@bclerdx #175 我是自己做的路由，只把需要的部分经由虚拟机连到深信服 VPN，所以不太会导致故障。另外这 VPN 并不常用的。

呃，我选择 Firefox Send 或者 https://transfer.sh/ ……

这种陌生电话，说中再多的信息，钱我还是不会转的，个人敏感信息也肯定是不会说的。
如果对方说自己是银行的人，我就去打银行客服。说是啥啥*机构，我就给他们打电话，或者本人去他们的办公地点问。

至于让我注销什么什么帐号？那你们就注销了呗。非要我亲自操作才能注销，那就让它放那儿不注销好了。

PS: 还是电子邮件靠谱，至少你知道对方是来自哪儿的。邮箱域名不是对方所声称的机构，或者 TLS、SPF 之类的验证不通过的，直接忽略了事。

原来背后还有着这样重大的故事： https://www.cnbeta.com/articles/tech/892109.htm

@no1xsyzy #36 这是 /dev/urandom 和 yes 的差别：

https://img.vim-cn.com/85/e96192a830c7b248c5bf60bbbf84c18156bc8d.png

@no1xsyzy #36 哦，我忘记说中间插入个 pv 看数据量了。你可以对比一下 /dev/urandom 和 yes 的生成速率。
@no1xsyzy #37 但是 gdb 是调用内核提供的 API （ ptrace ）的呀，是间接的呢。

@starsriver #26

> 硬件部分对于网络数据传输，也就只管二进制转模信号了，端口回来数据具体是个啥，怎么分配还是要软件来干，

是啊。剩下的都是网卡固件处理，然后转交 CPU 由 OS 继续处理。端口号都是 OS 的网络栈处理的。硬件要是干这个，那得把整个 TCP/IP 都给实现了……（感觉路由器都不想这么干吧）

> 关于网络系统有一本很厚的书，没看过。

那书里涉及到的东西太多了，远不止怎么收发数据这么简单。

> 随机数是硬件实现的，有一个周期，cpu 只是读取一下而已

不是所有设备上都有硬件随机数发生器的。

> 我记得在 linux 上对随机数在随机。。这种计算量对如今的设备，占用率不到万分之一。

你 cat /dev/urandom > /dev/null 试试？

> 硬件中断对高级语言写的软件层面作用已经不是很明显了

不写 OS 层的软件，谁接触得到硬件中断呀。OS 可不放心用户态的程序乱搞中断。

软件中断我没怎么了解过，刚看了一下维基百科。原来访存违例和调试啥的都是软件中断实现的。所以，软件中断也不是用户态进程能够直接接触到的。

我对硬件部分不太了解，因为我是软件工程师嘛。

@guolaopi #21 这个……内存的变化应该更明显。

@starsriver #14 你觉得你自己不蠢，可你说的也没几个对的。

不可能死循环轮寻 => 处理大流量的设备上是可能的，因为几乎每次轮询都有数据，效率比中断高不少
os 的触发器，就是别人说的中断 => 这里讨论的是硬件中断
每时每刻都会产生随即数来决定该为哪个服务分配资源 => 产生随机数挺累的，CPU 怎么可能一直去做，还干不干活了？任务调度是有算法的，一般使用带优先级的队列或者位图之类的东西，并不会使用缓慢的随机数
当对应编号及缓存地址存在数据缓存或者出现头数据，触发器会开始工作 => 并没有一个叫「触发器」的硬件会帮忙 CPU 做这部分处理
处理完后数据被寄存到内存里 => CPU 是先复制网络数据到内存里，再决定要如何处理。因为网卡的存储空间有限，你不及时处理就丢包了

@smallpython #19 「中断」是一个术语。CPU 工作的时候，网卡过来有事打断了 CPU，这就叫作中断。CPU 这时候根据中断向量表，找到对应于网卡中断的处理程序，然后 CPU 就知道有网络数据过来了。

只有在很繁忙的设备上才会使用轮询去处理网络数据。

当然，网卡是一直处于准备好接收数据的状态的。

@seeker #4 你没分清楚 bind 和 listen 是干什么的。bind 是绑定本地地址。listen 是设置 TCP / UNIX 套接字的状态，好让内核能够相应的处理。

正常工作的网络程序，也不是写个死循环 accept 就完事了。阻塞方案的方案，为实际处理事务需要通过子进程 / 线程来处理连接。调用 accept 的线程需要立即重新 accept 以等待下一个连接。不要写成我学编程的那样，不能同时处理多个连接……

accept 是阻塞的这说法也不对。accept 是否阻塞，取决于套接字是否设置了 O_NONBLOCK 标志。

@Fishdrowned #9 不对。网络处理有两种方式：轮询和中断。通用计算机中，通常操作系统会通过中断的方式来获知有新数据到达。

CPU 没事干了怎么办？降频省电啊！一直没事干怎么办？电力紧张的话（比如移动设备），可以休眠啊。

至于用户态的监听（ listen ）。呃，它就是设置一下连接的状态而已……用户态程序要获知新数据的到达，需要使用阻塞调用（ accept ）、I/O 复用接口（ epoll / poll / select ）、异步 I/O 等方案。

啊咧，几天前我终于收到更新啦～

@1608637229 #11 不为什么。不需要理解。这是 Go 语言规范所规定的：

> The capacity is a measure of that extent: it is the sum of the length of the slice and the length of the array beyond the slice; a slice of length up to that capacity can be created by slicing a new one from the original slice.

https://golang.google.cn/ref/spec#Slice_types

@sujin190 #12 你点一下「 run 」就会发现这个和 Python 的切片不一样的。