你要想，apple 在下什么样的大棋，macos 跟 ipados 本质区别是什么，或者说 macos 往 ipad 上下放，有什么样的难点。
首先说，两个系统一定程度上在 APP 上开始互通，所以从 OS 内核维度上，系统调用趋于一致。
然后说，因为两者源起的屏幕尺寸不一致，会导致其用户交互的方式不一致——从来没有过直接戳 MacOS 的屏幕进行交互的吧；自大屏 IPAD 开始，支持键盘和鼠标的交互了吧——所以进一步统一两者的交互模式，macos 和 ipados 融合。
最后，ipadmini 怎么办，同样都是 ipados，兼顾了 8 、10/11 、12 三种尺寸，我唯一在用的就是 ipadmini，我始终坚信 ipadmini 不是 ipad 的 mini，而是 iphone 的 max，同时随着柔性屏的使用，ipadmini 应当被同化入 iphone 体系，而 ipad(pro)应当归入 macos 体系。

所以，这不是装不装 macos 的问题，而是 macos 和 ipados 两条产品线怎么整合的问题了。

我觉得 AC68 的那个 CPU，做 NAT，大带宽会显得吃力

LZ 没有实操过吧，使用文件形式 MyISAM 存储的 mysql，过一段时间时间，表就得 optimize 一下清理碎片，INODB 会好一些。
这个事情涉及到 DBMS 的设计规则，最上层的表征当然是一个 SELECT 的效率，但是其中涉及到数据模型（表）的存储设计，操作系统的文件机制（磁盘分区格式）以及操作系统层以下的磁盘阵列机制（再往下就是单盘内部的缓存和存储组织形式）。
诚如楼上两回复所示，操作系统文件管理机制在其中，并不是最关键的，普遍 DBMS 会向 OS 申请一个较大的空间，然后文件系统决定是连续存储还是分片存储，所以为了进一步压榨，干脆把整盘独占给 DBMS——这个整盘并不是物理上的整盘而是经过了软硬件机制整合过的整块存储区。那么透过其本质，实际上就是 DBMS 在做一个文件存储系统，再进一步说，如果这台服务器事实上只处理 DBMS，那么是不是可以把 DBMS 和 OS 合并在一起，所以 Oracle 有数据库一体机，OS 经过调教，虽然还是 unix-like，但已经无关紧要了。

修正 5# 奥维地图

国内好使的，可能就是奥图了

两条音轨，时间轴同步

一人掌握密码前半段，一人掌握密码后半段。。。

iptables 丢弃了 ICMP 包吧

我不知道到底要干啥，但我知道如果光明正大的干，应该光明正大的自己搞一套互联协议。

@nc4697 哦，那个时候，拔掉，重插，如果还是，跳过 USB 这种硬盘盒，SATA 或者什么的直接连接机器（保证供电稳定），然后 chkdsk /f，能解决大问题。
当然了，当时那种情况还是要听硬盘是不是有固有故障。

在北京的话，四通桥数码大厦有个数据修复的，我弄过一次，盘没有问题，就是阵列（ RAID-0 ）毁了，然后不涉及拆盘，五千块钱。
大概是十多年前，SCSI 盘，可能是 146G*2 的那种。确实要恢复的数据好像连 1G 都不到。

@imn1 我倒是留着有数码相机以来的基本全量数据，2003 、2004 年前后，甚至还有当时扫描仪扫描下来的照片。现在 4T 双盘 RAID1 就是为了保存这些。中间还使用了冷存储手段。

然后说 LZ 的问题。首先执行了一次格式化，那还搞啥 chkdsk 啊。别动，除了读，什么都别乱动。
先排除硬件（包含逻辑）故障，硬件故障很容易分辨，听声音，正常是电机高速旋转和磁头挥动的声音，不正常是什么的，频率比较低得咔咔咔声音，重复、规律，而且伴随一读到某个地方就歇菜的情况，这是逻辑错误。另外纯硬件错误，那基本上读取、加载都很费劲，喀拉喀拉的。
如果以上问题都排除了，那就简单了，无非是分区表重建，再不济就是按个磁道检索重建文件。——只要软件好用，未必到第二种情况，重建分区表很快就完成了——基于只是常规的执行了“格式化”操作。
那为什么前完不要 chkdsk 呢，chkdsk 是基于现有分区表的检查文件系统操作，格式化后分区是新的，这个操作下去，是要重写磁盘一些信息的，这些新写入的信息，一定说不好会干扰到以往的有效数据——要挽救的数据被重写了那还怎么重建？

其实刚开始，事情很简单，但我目前估计 LZ 一顿操作，简单的事情复杂了。

最后是费用问题，该出钱的时候得出钱，但是更关键的还是得有耐性。DG 可能慢，那是必要过程，全盘全磁道检查，重建文件，磁盘越大时间越长。耐性，怎么就没有耐性呢？于是，从 10 块钱变成了 100 块钱，变成了 1000 块钱，别等到最后拆盘读盘，那可真是一万块钱都挡不住了。

#36 是吧，一堆自带的看起来方便但是各种卸载很闹心的应用，反而使使用变得麻烦。不用就卸载吧，一个一个全卸载干净。

看一下 UDP53 谁监听了，netstat -unlp，然后看配置做了什么上游 DNS，然后顺藤摸瓜。

@zhangsanfeng2012 28# 越整越高深了，LZ 吃不消。。。哈

这么说吧，ping 走的 ICMP 数据包，能 ping 通，证明 10.10.10.1 转发了 ICMP 包。
然后可以在 docker 里去 telnet 任何一台外网机器的 80，比如获取 t.cn 的 IP 之后，telnet t.cn 的 ip 80，这个能够检测 TCP 路径是否畅通，最后就是 UDP 是否畅通了，我的知识范围，还没找到一个能够检测远端 UDP 畅通的有效办法

@Peanut666 29#，我知道的，微信的聊天记录在 /data/data 里，这个地方始终是无权限查看的，然后聊天记录里的文件、图片什么的，现在转移到了 /sdcard/Android/data/Tencent 下，但是 /sdcard/Tencent 仍然有修改记录，不知道干了啥。

我用的 solid explorer，找个三方的文件工具，删删看吧。我是懒得跟张小龙斗智斗勇了。

18# ，感觉那个接受入站，应该是接受出站。入站成了外网访问你的 53，而不是你的子网要访问外边的 53 。

然后，合并 @caicaiwoshishui 的问题，openwrt 内置了很多个 dns 有关的服务，我当时是从 53 端口（查看监听程序），一个一个往上捋，adguard 、smartdns，还有几个，一个一个挨个关闭，各种拦截广告、防止 DNS 污染的，是好事，但也挺闹心，比如某些依赖或者看似广告网址的，无故被拦截，然后导致 APP 应用功能不能用，最后关掉各种 DNS 过滤器，一下子好了。

哈，firewall 不能直接关，我好像忘了这茬事了。因为 iptables 上是不是带着路由转发呢，哎，不对啊，路由和 iptables 应当是两码事。

从 6#的情况看，肯定 UDP53 被拦截了。你定义一下 firewall 的区域。

然后我没整明白那个 10.10.10.x 是个什么存在，也就是 192.168.1.1-10.10.10.1-192.168.20.x ？有点怪。。。

@iminto 15# 屎拉在 /sdcard/Android/data/com.tencent.mm/micromsg/里边，按照 anroid 的存储权限体系，你还是能把屎擦干净的。