xv6 的文件系统可以说是五脏俱全了，而且设计思想上和网络栈的设计非常类似，不同层之间提供了不同层次的抽象，保持了一定的透明性，读起来很爽。

UNP加入阅读计划了。

C++20要加入反射，这让我想起了之前跟别人讨论 RTTI 和反射哪个更邪教的时候还在说 C++ 应该不会有反射吧结果 C++20 啪啪啪打脸。
其实真正比较期待的是 coroutine 和 networking，module我觉得有戏但是兼容性怎么解决？

台下的 rust 和 golang 激动的拍了拍轮椅？

为什么 SYN 和 ACK 各占一个 SEQ？因为他们俩就是字节流的开始符和结束符鸭。

我们都知道TCP的SEQ是循环使用的，那么怎么判断SEQ1是不是在SEQ2之前呢？

Linux内核的实现，简直赏心悦目

这里其实有一个要考虑的问题是，在2**32-1范围内的任意SEQ值都有可能因为网络原因而在此刻到达，因此有一些隐含条件（可以见RFC793/5961）

另外如果假设seq空间是从0开始的一个圆，这里有一个前提是只有顺时针距离在2**31以内的才算before，不然就是after了——当然，这是非常合理的，也是本应该的效果。

TCP determines if a data segment is "old" or "new" by testing whether its sequence number is within 2**31 bytes of the left edge of the window, and if it is not, discarding the data as "old". To insure that new data is never mistakenly considered old and vice-versa, the left edge of the sender's window has to be at most 2**31 away from the right edge of the receiver's window.Similarly with the sender's right edge and receiver's left edge.Since the right and left edges of either the sender's or receiver's window differ by the window size, and since the sender and receiver windows can be out of phase by at most the window size, the above constraints imply that 2 * the max window size must be less than 2**31 ——RFC1323

为什么对于一个共享库不推荐静态链接 libc？

假设共享库 B 静态链接了 glibc2.23，现在程序 A 要用到共享库 B，同时程序 A 自己是动态链接或者静态链接了一个其他版本的 libc 甚至不是 gnu 实现的 libc，那么就会有下面一些问题：
1 libc 内部是有很多全局变量的，两份 libc 会导致其内部的状态不一致进而产生难以定位的 bug
2 libc 不同版本之间的内部结构体内存布局是有差异的，相互传递会导致问题
3 libc 本身是跟着内核版本走的，这也是影响 libc 向前兼容的因素之一

所以说对于 buffer 来说 unread 是邪恶的吗？

Tun/Tap 的原理远比我想的简单，但是复杂的问题是 lwip 好难懂....

摘自 https://segmentfault.com/a/1190000009249039

https://stackoverflow.com/questions/2649334/difference-between-static-and-shared-libraries
[Windows also has .lib files which are used to reference .dll files, but they act the same way as the first one]