任务栏通知区域没有了始终显示所有图标选项了，要逐个取消隐藏

装了这些就算没有用也能减轻责任。
你以为暗网上那些买卖数据的来源是从哪里来到。
以后有啥事，面对网警时你至少说自己电脑上装了这玩意，嫌疑也会大部分撇清。

xfs 也有 reflink 可以做到文件、目录级别的数据块共享，虽说是去重，但某些使用场景下可以算是伪快照。

库文件依赖也是很麻烦的问题，例如不同软件版本依赖不同 libc.so.6 。
就算是 Arch ，你自己更新间隔久了的话，没留意官网的关键公告，也用可能在某些时期滚挂了，只能用急救影像来恢复。
服务器就是要稳定，不到必要不更新。CrowdStrike 的教训还不够吗？

会不会是新内核 bigtime 问题
https://wiki.archlinux.org/title/XFS#Big_timestamps

虽然但是啊，既然是等保要求，那就关闭 80 端口吧，80 端口有非开不可的理由吗？
安全的话还是那个道理，做了可能没啥用，但是出事的时候可能就是你裤裆里的黄泥。除非你们 KPI 跟开端口的数量挂钩。

既然想到结婚，那么应该也可以预先做一下婚后经济财务规划。两个人在收入稳定下，每年家庭收入支出先做个预估，看看财政状况 ，估计一下日后孩子、房子、车子的成本，达成共识大概什么时候花什么钱存多少钱也是成年人责任了。尽量不要考虑借钱结婚，婚礼只是个仪式，为了面子在上面花太多影响日后两口子生活质量就丢了里子了。如果大家感情真挚，两边父母也不是打算在子女身上吸血的，应该容易做工作的。

会不会是楼主理解错需求了？是不是因为针对公司不公开财务，所以才有需求通过 AI 分析公开数据推算财务状况。例如饮食公司根据新闻里开张的门店数量，人流量，消费水平等等侧面数据推算之类的？

深度自带的终端不行吗？有标签页，有透明度，有雷神下拉模式，有远程服务器管理功能，我觉得都不差了。

@EyebrowsWhite sudo 就是让你可以临时以系统管理员 root 身份运行，脚本以 root 用户身份运行，自然脚本里面的一切命令都是 root 来跑的，对于 root 来说哪个用户的文件就算 600 都能查看。

有一种实践方式是，用 root 编写备份脚本，然后/etc/sudoers 里设置允许某个普通用户运行这个脚本。

要从 https 数据中拿到明文密码，一种可行路径是：扫描关键服务器的信息泄漏漏洞->获取服务器私钥->攻击服务器侧其余薄弱服务器（如测试环境）->横向渗透或抓取服务器段流量->解密服务器 https 流量。通过此途径，可以在没有取得关键服务器的管理、修改权限的情况下，仅凭中风险漏洞就能从流量中获得用户密码等信息。
还有更多其它方式。现在复杂的部署环境，我觉得大部分人都只能负责一小块，服务器、网络、WAF 、负载均衡等等不可能都完全由你掌握，例如有些设备由于性能还要求你先卸载 SSL ，光靠 https 一劳永逸不实际。
也许你会认为这是服务器安全加固责任之类问题，和 https 无关，但是在 HW 、会议等敏感时期中一旦出现安全事故，保不准哪位哥们为了减轻责任，就是把你密码明文传输赖上，为了撇清责任你的上级也不一定会为你说话。
是的，HASH 一下它还是有其它风险，但我自己觉得，多做这一步，不是为了保护数据，而是为了不用提桶跑路。

我觉得楼上很多人对数据安全问题还是了解有限，如果你不是这里数据安全领域里摸爬滚打过，就不要轻易下结论。如果你身边有参加过 HW 的，或者打过 CTF 的同学同事，先去和他们请教一下 HTTPS 用明文传输密码的风险，了解一下为何有了你们都觉得安全的 https ，在 CTF 里还是有 wiresharp 分析 https 流量的赛题。

@luxor 目前的安全防护都趋向于零信任安全的理念，你不能指望只靠通讯协议可以完全对抗中间人，https 虽然对通信内容进行加密，但建立 https 过程仍然有很多步骤是有可能钻漏洞获进行中间人攻击的。当然安全的程度也要考虑成本，但是如果你前端采用 HASH 传输几乎就是 0 成本的，为何不做？万一你这个项目出现信息安全事故，遇到严厉的领导或甲方，你就算再怎么辩解这个用户密码不是从你前端漏出去的，追责时这个偷懒行为都够你喝一壶的。

前面说 Hash 传输没意义，这只是从单一系统角度视角考虑的结果。
要知道现在没有系统会保持明文密码，是因为用户密码的泄露，不但对本系统有风险，更是对用户使用的其它系统都照成风险，因为很多人是多个系统登录注册都用同一个密码的。
同理，将用户密码明文传输，就会出现通信链路中通过中间人攻击可能获取到这个密码，给攻击者有机会利用这个密码试探将用户所有可能使用的系统，扩大了用户损失。

@lucasj 附议
我的实践经验也是 find 的 -delete 参数比 xargs 并行删除要快得多

sid IN (0, 1, 2) ORDER BY datetime 很显然不能完全利用 sid 和 datetime 的联合索引。
和前面有人提到的，sid IN (0, 1, 2) ORDER BY datetime 和 sid=n ORDER BY datetime 后再 union,逻辑上是不等价的。
它最多会用 index skip scan 找出所有 sid IN (0, 1, 2)，然后直接内存排序 datetime ，这个排序联合索引是没能起作用的。