英文讨论可以用 regex expression true subset 做关键词搜，不过搜出来的多是 SO 的问答或者其他讨论串

中文倒是有人写过代码解决方法，原理用的有限自动机判断是否等价 /包含（判断此人是个计算理论 /编译原理大神😂）
wu-kan[.]cn/2020/07/03/%E6%AD%A3%E5%88%99%E8%A1%A8%E8%BE%BE%E5%BC%8F%E5%85%B3%E7%B3%BB%E5%88%A4%E5%AE%9A/

OP 你有心思可以就着参考实现一下

要满足题述要求的完备，需要对 A 和 B 这两个正则做形式化证明（ A 可转化为 B ，属于 B 的特例，B 则不可转化为 A ）
感觉这种工作得看学计算理论的那帮人有没有造出相应的轮子

各种方案绕了一圈
最后还是发现用 5 米的 usb typec 全功能线接个 ipad 插电视上好使，ipad 就当遥控器了

此贴挺适合 block 某一类二极管的——
说着某个平台充斥着二极管，自己却做着二极管的事

群星 stellaris

@kilotiger #17 喜欢您的素质，不过素质仍有待降低（但也请警惕被封号）🤣

好东西，支持一下

@lookStupiToForce #7 回错贴了，无视掉我...

好东西，支持

op 的需求好奇怪
用电脑监听也是加个设备
用其他监听设备也是加个设备
有啥区别？
还是说就是想花一个调音器 /专业音箱的钱？

vmware

我个人总结的一些个人养老金注意事项，欢迎纠错：

· 入账资金不做其他操作只算活期存款利息

· 想要高于活期利率的回报，需自选投资品，自选投资品除储蓄类产品其他无保底

· 个人养老金领取时缴纳 3%个税👍👍👍👍👍👍👍👍👍（暂不清楚这部分个税的基数怎么计算）
"在领取环节，个人领取的个人养老金，不并入综合所得，单独按照 3%的税率计算缴纳个人所得税" <- news[.]cctv[.]com/2022/11/25/ARTILywb97axIBejTuqL96dG221125.shtml
（作为对比，我国普通存款产品的利息税自 08 年已停收；大部分投资品也是免征个税，只有千分比量级的印花税 /手续费之类的）

· 入账资金中途不可随时支取，需要满足“一定”条件👍👍👍


基于此：
谁有闲钱谁爱买谁买
你前期省的个税，后期可能都会通过 3%的税还回去
但凡有点投资知识，🤡🐶❌🛍️

xyplorer: 功能超强的文件资源管理器

anlink: 让电脑连接并实时控制安卓手机

mouse without borders: 如果你的面前有多个显示器连接着多个 win 主机，用这个微软出品小程序可以免 RDP 直接一套键鼠操控多个 win 主机——鼠标移到哪个屏，哪个屏的主机就会占用键盘。使用感受取决于 wifi 质量，wifi 质量好则可以体验无感切换

Tai: 在 Windows 上统计软件使用时长的小程序。v 友出品，github 开源 www[.]v2ex[.]com/t/822001

parkcontrol: process lasso 厂家出品的方便调整 CPU 激活的核心数和 CPU 频率的小软件

seer: 仿 mac space 预览，支持的文件类型很多

sharex, listary, quicker, winscp, winMerge 都有人说了

eagle: 强大的图片和其他音视频标签资源管理库，mac 上也有，方便多端共用

irfanview: 小巧但超级轻便迅速的图片查看器，也可以支持简单的图片处理

openark: OpenArk 是一款 Windows 平台上的开源 Ark 工具. Ark 是 Anti-Rootkit （对抗恶意程序）的简写, OpenArk 目标成为逆向工程师、编程人员的工具，同时也能为那些希望清理恶意软件的用户服务 <-- github[.]com/BlackINT3/OpenArk/blob/master/doc/README-zh.md
用的多的还是拿它来监视热键占用（需要进内核模式）

你甚至可以让产品经理写个框架文档 /流程文档，让它去仓库里照着文档分段写出伪代码（它不能一次返回太多，得引导；返回的代码部分可用，还是得程序员帮忙改）

这东西再完善一下，什么低代码都省了，程序员也可以再就业成 AI code 的 debug 专员直至被裁撤
以后真的只能“人人都是产品经理 /架构师”

@hahastudio #80 造假这个事知乎有人提过了，所以并没有（。

@Exp #10 IO 状态得 SSH 进去用命令看，iostat 、sar 之类的
不过如果你确定当时只有 1MB/s 左右，那这个速率可以肯定是包含大量随机访问了。

我详细回看了一下以前的文章收藏，感觉可能是你的使用情景触碰到了文件系统的瓶颈（也不知道你用的啥文件系统，截图里没看到。ext4 ？ btrfs ？），贴一下看对你有没有帮助吧：

www[.]zhihu[.]com/question/22555963/answer/1671045642
"""
单个 1G 的文件，在现代文件系统里，可能至多需要十次不到的寻道就能全部读取；而 1024 个 1M 的细小文件呢，那就相当于 FAT 时代、存在一千个文件碎片的单个大文件——起码多了一千次寻道呢，怎么可能不慢。

事实上，这样算还是算少了。因为磁盘驱动必须先读取文件分配表，然后才能拿到“指针”、才能去按照“指针”指示寻找对应的扇区；那么对 1G 的大文件，文件分配表寻道一次，扇区寻道一次，差不多就够了；而对 1M 的一堆小文件呢，文件分配表寻道 1024 次，每个文件的首扇区又要寻道 1024 ，实际多了两千多次寻道。

按每次寻道需要 15ms 算，额外就需要 15X2000=30000 毫秒，也就是 30 秒时间；而现在的硬盘在顺序读写时平均读写速率可以飙到 170M/s 以上；哪怕按 100M/s 算，1G 的文件 10 秒也能传完了；结果寻道愣是多寻了 30 秒——慢了足足 3 倍！

而且，这里仅仅算了读取；写入时，小文件也需要先写文件分配表后写内容，这显然又是一堆寻道……不过这个场景过于复杂（比如同个磁盘不同分区拷贝、不同磁盘之间拷贝等等，细节各有不同），就不深入分析了。
"""


如果要我来猜的话，就是系统批量写入的时候，是一个顺序，记作 A ，读取的时候，操作系统提交给文件系统的是另外一个顺序，记作 B ，B 相较 A 已经不同了，而文件系统将 B 优化后的读取顺序，记作 C 。C 虽然已经按照磁盘文件实际位置做了大量优化，但其相对于 A ，还是有大量乱序，导致了随机 IO 占比过高

你不妨监测一下群晖在你说的这种移动大量文件却相当慢的情形时，其硬盘 IO 状况（注意是 IO 数量不是硬盘速率）
如果 IO 量简单换算后（ IO 数除一下文件总数）相比移动单个小文件时比较大，有理由怀疑群晖在此过程中真的对文件进行了“碎片整理”

类似于 windows 的磁盘碎片整理，数据库的收缩 /真空功能，能理解吧？

另外就算没有碎片整理，非连续存储空间的零散文件的 IO 本身也挺费时的，你说的情形同样适用于删除文件（也是改个标记的事），这种情况你可以 [镜像硬盘] （理论上镜像硬盘可以完整复刻文件碎片化情况）后再做个删除测试