ghost 多老旧的东西了，基于扇区的备份，单线程处理+压缩，不仅慢而且空间效率低下，最好别再用了

建议使用 Windows 从 Vista 开始的“官方”打包方式也就是 install.wim 文件的打包方式。

重启进另一个系统（或者 Windows PE - 本质上还是“另一个系统”），然后 CMD 找找 Dism /Capture-Image 命令的用法打包就行。如果想方便或者操作简单的话也可以用 GUI 软件例如 Dism++。

如果你直接用 Win10 安装盘里的 install.wim 运行 Dism /Append-Image 的话速度还能快一点，因为相同 /重复的文件可以不用重复添加和压缩，运行速度更快。

CPU 烧了的可能性比较小，听你这么说更像是主板 GG 了

docker 就不是给 linux 以外的系统设计的，所以 ddfw/ddfm 什么的就别吐槽了，老老实实找个 linux 主机或虚拟机跑吧

于是楼主白嫖到了 3k+ 铜币

你可以用 GitHub Pages 搭一个“服务器”来存储和提供这个变量

明文 HTTP 协议可以看 Host 头，常见的 TLS 加密可以看 SNI （明晚的域名），这也是现在拦截 HTTPS 依赖的东西。

TLS 1.3 新增的 ESNI 才是真正的全局加密，什么都看不到，跟 HTTP 版本没关系，HTTP/2 就已经要求加密了，但是 SNI 还是明文的，没有强制要求，HTTP/3 这方面没变化，只是改了数据传输的方式

那就经常去看，锻炼语感

Linux 虚拟化标配 QEMU/KVM 不香吗，前端用 libvirt 管理

计算存储分离，SAN，虚拟机使用的虚拟硬盘并不在运行虚拟机的主机上，而是有专门的存储阵列通过网络连接，所以虚拟机开机时可以任意分配主机

罗技 G 系列就好，自用无线版 G304+G502 和有线版 G502

就算你有改进你有优点，也没法否认你这是像素级抄袭 Notion 的设计

把 DNAT 都换成 REDIRECT 吧，至少 REDIRECT 到本机后接收到包的进程可以获取 SO_ORIGINAL_DST 来帮你转发

考虑到摄像头（感光元件）的功耗，不插电的就别指望了，就连行车记录仪都要接电源

> 因数多了，会有同比例的 欧拉 n 出现，我依然要验证哪个 欧拉 n 是对的

ϕ(n) 是一个确定的函数，对于任何正整数 n，ϕ(n) 都有唯一确定的值。只要将 n 的全部质因数找出来，就可以算出这个唯一确定的值，这里有什么问题吗？

如果 pq 都是合数的话，那么质因数在 pq 中怎么分配是无关紧要的，例如 p=12, q=14 和 p=8, q=21 会得到完全一样的结果。这是因为 ϕ(n) 是关于 n 的函数，与 pq 没有直接关联。

另外上面那个算式有点偏差，应该是 ϕ(n) = n*(1-1/p1)*(1-1/p2)*...*(1-1/pn)，这样就可以看出它与各个质因数的顺序没有关联了

> 如果 p，q 是合数 n=p*q 对 n 做质因数分解就简单 ？

这是因为如果 n 有 6 个质因数，那么其中最小的那个肯定不会超过 6√n，这里 6 可以换成其他数字。当 n 的大小确定时，显然质因数越多，每个质因数就会越小，从而分解（找到其中的一个或多个质因数）也会更容易。

> 还有就是 假设 p，q 都是质数，那么 n 的因数分解只有 1 种组合 就是 p*q，不会有第 2 种（除了 1 ）？

这个问得我一时无语凝噎……回去补补整除和同余相关的数论吧

没错，RSA 安全的原因是 “大质数分解是困难的”，这并不是直接的原因，而是经过了以下几个已知的命题

1. 由 e 求解 d 需要知道 ϕ(n)（需要的额外知识）
2. 对于 n=pq （两质数乘积），ϕ(n) = (p-1)*(q-1)（即分解得到 p 和 q 是一种破解方式）
3. 没有已知的更好的求 ϕ(n) 的方式

因为有了 3，我们才能认为 RSA 的安全性依赖于大质数难以分解。

对于任何非对称加密，其安全性的直接保证都是 “由公钥计算私钥是困难的”，只不过对于 RSA 可以推导到质数分解。

当 pq 都是质数时，对于 m 位长度的模 n，求出 pq 之一的期望复杂度是 2^(m/2)（例如，对 256 位的 n，分解质数的期望复杂度就是 2^128 ）。如果 pq 是合数的话，这个期望复杂度会直接下降，例如当 p 和 q 各有 3 个质因数时，期望复杂度就只剩下 2^(m/6) 了。显然没有人会在相同长度 n 的情况下选用安全性更差的方案。

其中欧拉函数 ϕ(n) 表示 1 到 n 之间与 n 互质的整数个数，参见维基百科： https://en.wikipedia.org/wiki/Euler's_totient_function