同一个链接内容不固定，早晚被微信给屏蔽。

hash：通常情况下不能回到 hash1 。
hash 主要用于提取信息摘要。y=hash(x)，从 x 种状态经过 hash 运算转换得到 y 种状态。
通常情况下，y 的状态数比 x 的状态数少。所以，必然有一部分 x 的状态需要被转换为同一种 y 状态（哈希冲突）。
所以在这种情况下，必然有一些状态经过任意次 hash 计算后，无法回到自己的原本的状态。

举一个例子：hash(x) = x % 2 。举例：初始 x0=3 ，x1 = hash(3) = 1 。永远不会回到 3 。


加密：不清楚……感觉上这与魔方的问题是类似的，都是在有限群做相同变换。
但有一部分对称加密算法的加密、解密过程是一致的。比如 AES-CTR/Chacha20 。
再比如 AEAD 类算法，这类算法是流加密+HASH 函数的组合体，比如 AES-CCM ，是 AES-CTR+AES-CMAC 的组合；再比如 AES-GCM ，是 AES-CTR+GHASH 的组合体。起机密性保护的流加密部分，就是原流加密算法，性质完全相同。

对于这些算法，由于加密、解密过程是一致的，你只需要把第二次加密看做是“解密”即可。对原文加密两次必然会得到原文。

@bl 拿到任意代码执行权，就啥都能做了。

比如直接系统调用 /bin/bash 。用 /dev/tcp 打个管道。啥都能扔到系统里跑。

能放得下一个 loader 就行了。靠这个 loader 继续加载更多信息。

x86 的 BIOS 只给了 510 个字节，就可以把整个操作系统跑起来。

@locoz 现在硬盘真的没这么容易坏，做好 RAID 就可以了。我 NAS 已经用了 5 年多了，强制断电少说也有几十次了。没有一次断电导致硬盘坏掉的。
我从最开始两块盘，陆续加到现在 4 块盘。除了有块 2017 年买的西数 WD20EJRX 2TB 盘去年自然挂掉，被我换掉，到现在其它盘还都很健康。

还有块 2017 年买的盘，SMART 信息看，Power-Off_Retract_Count 已经被我刷到 294 了。这盘依然没有任何错误。

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 178 170 021 Pre-fail Always - 4083
4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1872
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 075 075 000 Old_age Always - 18305
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1212
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 294
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 1695
194 Temperature_Celsius 0x0022 112 100 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

找能开 25 端口的云平台（或者找公司商宽 ISP 备案开 25 端口）+自己域名+mailu 。

观察到 A 、B 范围有限，这么困难的问题，可以考虑打表解决。

比如中国移动的超大 CGN 。一个省公用一套 IP 出口。省内通过 100.64 通信，省外 NAT 到公共 IP 出口。

从这些公共 IP 来看，根本分不清到底来自省内具体哪个地方，自然就无法在省一级更精确定位了。

简历发了两个星期都没有任何回复……看上面回复，已经有很多人出现这种情况了。你们要不自己检查一下？

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

大概是这样吧：

编译器报错变量不能 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 ？