> ”导致我自己写出来的代码我都不理解什么意思“

大概是这样吧：

编译器报错变量不能 Send -> impl Send for XX{} -> 编译器报错 Send 是 unsafe -> unsafe imple Send for XX{} -> 编译通过-> 运行 -> 崩溃 -> Fk Rust!

@RedBeanIce 因为 master 和迭代主分支可能共享同一个 commit 。这种时候从哪个分支拉都是一样的结果。

你可以认为分支是一个特殊的 TAG （实际上分支和 tag 在 git 底层是 reference ），他们只是标识一个 commit 。注意，这里是一个。

当你在 master 分支做一次提交后，git 会根据当前 master 这个 ref 找到 commit id ，将新 commit 的 parent 设置为这个 commit 。然后移动 master 这个 reference 到新 commit 。
从 git 角度来讲，分支只是标识一个 commit 而已，并不记录其它信息。真正有前后关联关系的是 commit 自己。
你甚至可以直接用 git reset --hard 去强行移动一个分支到任意一个 commit 。

所以如果你的仓库有这些 commit：
```
a->b->c
\ \->d
\-e
```
假设 master 分支指向 a ，迭代主分支指向 b ，开发分支分别指向 c 、d 、e 。此时，你想知道”c 是从 a 拉的，还是从 b 拉的“，这个问题是无解的。
因为开发分支 c 可以是从 a 拉的，但提交了 b 、c 两个 commit 。也可以是 b 这个 commit 已经存在，然后开发分支 c 只提交了 c 这个 commit 。
这两种情况在 git 记录里是一模一样的，无法区分的。

GPT 的分区类型标识。Linux 下没啥用。https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

EFI Boot 里可能有点用。比如用来定位 efi 分区。

附文档 https://git-scm.com/docs/git-merge-base

git merge-base 是你想找的吗？或者它的 --fork-point 参数？

TCP 缓冲区大小在内核是随时变化的。即便有接口让你拿到当前缓冲区大小，在系统调用返回之前，这个值也可能发生变化。
这个没啥用啊。

如果你担心数据延迟，就不应该使用 TCP 协议。
如果你担心 Write 阻塞，你可以用非阻塞操作，或者异步 io 类操作。

你能再更详细的描述一下你的需求吗？

10 万亏 26%

@hisune 7 月你会接到税务局电话~10 月你会上失信名单。

@geekvcn AMD 这种嵌入式的芯片，请问在哪里有供货渠道

@duke807 这个双向链表是为 safe Rust 提供一个链表实现，使 safe Rust 可以在 safe 的上下文上使用链表。
这种情况下，显然不能用 C 实现链表，然后通过 ffi 给 safe Rust 来用。

没有 unsafe Rust ，哪来的 safe Rust ？

@fanxasy 挺好。如果不做处理，直接 POST 传给后端就更好了。

假设你有条消息，m 。要生成他们的密文，c 。你没有用 HASH ，也没有添加随机数。使用了原始的 RSA 做了 “加密”。
```
c = m ^ d
```
然后你把这东西，通过中间路由，发给了公钥方。
这时候，通信中间，有个路由算了个 s ，把消息改了，传给了公钥方
```
c' = c ^ 123 = (m ^ d) ^ 123 = m ^ (d * 123) = m ^ (123 * d) = (m ^ 123) ^ d [mod n]
```
公钥方做解密过程
```
m' = c' ^ e = (m ^ 123) ^ d ^ e = (m ^ 123) ^ (d * e) = (m ^ 123) [mod n]
```

m ^ 123 对你的业务有没有影响呢。。说不准。万一有影响呢？有影响不就被中间这货坑了么。

那 RSA 签名咋能用的呢？签名主要把 m 换成了 HASH(m) 。（实际应用时还有 padding 等更多运算）。最后验签方也是计算消息的 HASH 值，对比 HASH 值是不是相等。

即便中间这货给换了签名，那公钥方最后做解密得到的 也是 HASH(m) ^ 123 。

中间这货需要构造一个 123 ，使得 `HASH(?) = HASH(m) ^ 123` 里的 ? 有意义是很困难的。

这里唯一好找的就俩解，一个 把 123 换成 0 ，一个 把 123 换成 1 。

换成 0 的话，整个 HASH 值就是 0 ，然后 就看 HASH 0 为 0 的消息对业务有没有影响。（实际应用时，会通过加入随机数等操作避免这种情况。）

换成 1 的话，那就是原消息。中间人无害转发，也挺好。

@Fdoit 哪个厂啊。。绿厂都不敢这么玩。

"都需要用到 2FA 了，说明你的账号密码已经泄漏了" 非常不同意。

在公司电脑登录我的 gmail 帐号，HTTPS 是被深信服 MITM 攻击过的。不开启 2FA ，我的 github 帐号登录信息深信服都能拿到，而且长久使用。

我本人是不信任深信服，但又无法不在公司使用 Google 的服务，所以 2FA 变成了仅有的解决方案。

你不要卡住不就行了。。需要改改非要让代码卡住的问题。

@statumer h264 是没有时间戳的。有时间戳的是包装文件，比如 mp4 。

补充一下。伪造 IP 很容易是伪造数据包源 IP 。即可以很容易作为某个 IP 发数据，但很难按照 IP 路由收到回应包。

@PerFectTime 像是带 port knocking 的防火墙？

你这种想法是会提高安全性。但没办法在大规模部署后还能提高安全性。因为 IP 路由协议的问题，**伪造 IP**是一件很容易的事。作为安全方案，这就是它的致命弱点。

这样就很难把它作为一个正式的商业产品推广。

@Nitroethane 这是没有 swap 的情况。有 swap 的情况下，部分页面会与 swap 建立 backing file 关系。建立好关系之后，会一样处理。