likelylee

可以考虑用 resticprofile ，直接在配置文件里指定 schedule 就可以了，我本地已经稳定运行两三年了。

如果你需要在打开窗口的快速文件夹跳转，尝试 listary 或者 flowlauncher
如果你需要插件生态，尝试 flowlauncher 或者 raycast beta
如果希望和 mac 平台统一，那就 raycast
如果不想装第三方，那就 powertoys 自带的 command palette
如果不喜欢 alt+space 打开，那就 listary ，可以双击 ctrl
其他的相比上边基本没有显著特点了。

rustdesk 在 wayland 环境下不能无人值守。比较可行的做法，要么是直接端口转发直接 rdp 客户端连接到 krdp ，要么是通过 tailscale 或者 zerotier 等虚拟组网，或者 vpn 回去之后 rdp 连接。krdp 我没深度使用过，但是 gnome wayland 下的 rdp 服务器是可用的，但也仅仅是可用而已。如果实在有非常高的远程桌面的需求，目前建议还是上 x11 。
所以我现在的解法是 windows 机器加移动硬盘 vtoyboot 到 linux 环境...

从疫情元年到现在我用 unraid 已经 5 年多了，除了 smb 速度是个最大的问题，其他方面我还没有遇到过问题。网络部分我用 r5s 独立了主路由+翻墙之类的功能，除此以外 30 多个 docker 和 2 个虚拟机都是架在 unraid 上，硬盘没做 raid 因为比较乱，一个 4T 的 nvme 做 cache ，一个 12T 做主存储，一个 4T 和一个 2T 做备份，通过 user script 把主存储上的重要数据定期 rsync 过去，平时都是停转状态。
飞牛之类的之前试过，但是他的功能都能有 docker 替代，因此没有长期去用。不过如果都考虑用飞牛了，直接底层 pve 就得了没必要上 unraid 。我没上 pve 的主要原因就是 unraid 买的早...

im 类的端到端加密，请搜索 gpg 的 email 实现机制，或者 smime 的实现，都是类似的。
简单的逻辑，个人到个人的场景下各自交换公钥，通过公私钥协商会话密钥，会话密钥加密消息体。群组消息的话，首先随便一方生成对称密钥，使用组内所有人的公钥分别加密对称密钥放在消息头，每个人拿到后用自有私钥解密，然后解密消息。
群组这个思路是相当早年看到的，不保真现在 gpg 是不是还这么干。
至于你说的 4 位数字，我没用过 x 的 app...确定不是身份验证用的？也有概率是用来派生对称密钥然后解密私钥。

我们办公要求用 thunderbird ，但是手机端我装的是 canary ，自带 gpg 工具，不需要像 thunderbird 额外装 openkeychain 。而且总体颜值比大部分邮箱类软件要高，除了付费......我是早年的付费用户，当时非常便宜，现在似乎贵了不少。

@WngShhng 你看啊，如果你不考虑认证要求，不考虑最佳实践，那你的应用不论你想怎么实现都可以。现在的问题不是你想让大家认可你这个 RSA 的实现，那对不起至少我不太认可。
如果你的出发点是 android 的安全性，可以考虑调用 TEE 去做密钥相关处理，这也是最佳实践的做法。如果你连 TEE 的安全性都存疑，可以考虑不支持 android 只做 iOS 。但是不论如何，你希望说明你的 RSA 服务器实现的安全性高于 TEE ，那至少你得从各方面都给出来做够的说服力，而不是仅仅重复“Android 本身并不安全”，因为国内几个手机的 CC MDFPP 认证也是我做的。
自己实现一套机制没问题，我也经常会帮客户想一些奇怪的思路，比如白盒加密之类，但是不代表这些方式是足够安全的，只是在接受了某些风险的场景下可用。对于你现在的应用场景，是不是你得先想明白到底需要应对什么风险或者安全问题，然后才去看你的实现机制是不是足够的？

@WngShhng 想突出端到端就不要加服务器，忘了就忘了，或者参考 bitlocker 提供离线的恢复密码的助记码之类的方式。如果一定要做 RSA 且服务器保存，那么至少参考上边几楼的说法，做好身份认证之类的事情，比如额外引入 CA......

怎么说呢，我先摆资历来增加说服力，国内的 FIPS140-2/3 认证，基本都是我做的。如果有做过认证的或者关心过认证的，应该就知道我是谁。
当然你的产品不做认证前提下，随便怎么开发都没问题，但是如果你希望哪怕参考一点所谓的“最佳实践”，你就会发现那个“大神”说的大差不差。语气问题可能以下我也有，见谅。
端到端加密没有一个准确的定义，但是按照常规的实现思路来说，“没有第三人持有任何可用于解密的材料”这个应该是共识，那么按照你现在的做法引入一个 RSA 公私钥做加密，私钥在你的服务器侧用作密码恢复，先不提所谓的算法安全强度的事情，至少你说端到端这个就不准确了。这里不讨论 RSA 用于加密的一堆要求，也不讨论怎么身份认证的事情，就单纯存在一个中心点可能会解密密码这个场景，作为明确有端到端需求的人可能就不选了。
其他的问题，诸如 KDF 密钥派生算法，常规的方式都是考虑把密码作为 PBKDF2 的输入，提高 iteration 次数到 10000 以上，然后用派生出来的密钥作为 AES 密钥使用。AES 的 IV 要看使用场景来判断长度和生成方式，通常来说至少是随机数 96 bits 以上。在做到这些之后，你怎么做拼接 base64 之类的都无所谓。
我们都能理解不要自创算法的重要性，但同时正确使用算法，正确的组合算法也相当重要。