光从排列组合的数量来讲，并不是能允许的密码数量越多越就越安全。

一个禁止 123456 和 654321 的系统会比不禁止的安全，因为这两密码太常用了。

Windows 10 IoT Enterprise LTSC 2021
一直支持到 2032

按照官方文档给的步骤更新就是了。

上游在打包的时候，自然会控制不同版本的仓库间的包不会出现太大的跨度。比如某个包从 v1 升级到 v2 ，这种升级一般都不会出太大的问题。

滚动更新是因为根本无法预测到底是从哪个版本升级到哪个版本，所以长时间不更新后再次更新，从 v1 一下升级到 v10 （只是据个例子，现实不一定会遇到），遇到复杂的依赖问题，自然容易滚挂。

对于旧包，很多包管理器都提供清理不再需要的依赖的功能（比如 apt autoremove ），或者清理旧版本仓库中存在的包，但是新版本仓库已经移除的包（ aptitude purge '~o'）

@zizon 试了一下，好像符号链接就行，虽然每次从其他机器 pull 都要手动创建符号链接。

@CivAx 你说的收邮件那更是另外一回事了。也是需要域名所有者设置 mx 记录到 mailgun 的邮件服务器，从而 mailgun 能接收邮件，再给你 route 到 outlook 。

如果你要收第三方邮箱的信件，要么通过 IMAP/POP 用户名密码读取对应的邮箱，要么设置 mx 记录从而域名下所有邮件都发到你这里。这都是需要第三方参于的。
而发邮件的逻辑却是直接采用了伪造发信者的方法。正是从收发邮件的逻辑来比较，我认为发邮件允许用户随意伪装所存在的不合理的地方。

@CivAx 这个特性和 mailgun 、amazonses 之类的邮件服务是两码事吧。

mailgun 之类的服务，通常是通过域名所有者设置对应的 SPF/DKIM/DMARC 记录来完成，并且收发邮件时接收方也可以验证。

比如接入 mailgun 这类服务提供商，通常是把子域名解析到第三方的 SPF/DKIM ，并且把 DMARC 记录里 aspf 和 adkim 设置为 relaxed ，从而允许子域名可以作为根域名通过检查。这样 mailgun 则可以通过子域名代发邮件，收件人也可以通过验证子域名的 SPF 和 DKIM 签名来验证。

类似的，包括前面有人提到的同个部门之间可以相互代发，如果子域名和根域名本身就属于同个实体控制下的，所以允许他们相互代发很正常。

但是 outlook 这种是直接修改 From 成另外一个域名，这完全是任何一个邮件伪造者的做法。

@keepRun CDN 已经用了 CF 了，不想有太多的服务依赖单一提供商。而且想要 self host 各种服务。所以最后觉得还是自己搭建比较好。不过邮件服务器似乎比 web 服务器更难管理。