毫无疑问你该用当前最新的那个 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 的切片不一样的。

@zichen #10 大概是因为 channel 的实现里有个锁，然后没有接收者的时候它就死了？

Go 的 channel 不能在发送时知道有没有接收方吗（不管它在不在接收）？ Rust 的 channel 如果接收方不在了是会返回错误的，Go 应该也能做到的吧？

我也发现这个了。既然用了你的产品，你有规定，要收集数据可以。你就不能搞个 HTTPS 让数据安全点儿？

@oovveeaarr #9 我的「高级选项」长这样： https://i.loli.net/2019/07/28/5d3d4ed8ed9a686285.jpg

@A18524478970 #31 那我再等等好了。我还以为就我的系统被落下了呢。