@Ljcbaby #12
@damngoto #16
我的 522 似乎是回源到腾讯云 CDN （中国大陆）超时了，1014 是 1xxx 错误码，确实不一样。

我也是这样用的，现在访问的结果是 522 ，不知道楼主是不是也是这个 http code

会，大概每月更新一次，但也遵从从内到外的原则，本地虚拟机更新没有问题再上内网服务器，然后云服务器

@pagxir #31 op: ?

@nevin47 #20 有 issue 的话等官方支持也不是不行
想到一个邪道，直接用支持的手机（已经 root ）挂载并取出需要的文件


@Buges #21 如果有改善，那为何不做呢，Dnsmasq 不都逐步接受了 fastlookup

@Buges 建议你自己开帖批判这一问题，我希望的是寻求工具来解包 img 。

另外，没有特别优势不代表没有优势，在任何情况下我们都希望有更好的的东西出现的。

@nevin47 #14 github.com/microsoft/WSL/issues/7257 似乎 WSL 还不支持 erofs ，内核参数不对

@anguiao #3 https://github.com/microsoft/WSL/issues/7257 似乎 WSL 还不支持 erofs


@nevin47 #10 确实希望有人做解包，要往虚拟机里丢一次还是挺麻烦的

@Buges #7 自我纠正
> 其实 Linux 压缩文件系统也早就有了：Squashfs ，但这个文件系统并未在手机系统中流行起来，甚至低端设备也未采用。原因在于：
>
>> 我们为何不使用 SquashFS ？
>> 我们尝试过 SquashFS ，但无法实现高端设备所需的性能。我们不会为手持设备使用 SquashFS ，也不推荐这么做。
>> 更具体地说，使用 SquashFS 时，系统分区上节省了约 50% 的大小，但绝大多数压缩率较高的文件都是预编译的 .odex 文件。这些文件都具有非常高的压缩比（接近 80%），但系统分区其余部分的压缩比要低得多。另外，SquashFS 在 Android 7.0 中引发了以下性能问题：
>> 1. 与以往的设备相比，Pixel 具有非常快的闪存，但并没有大量的空闲 CPU 周期，因此虽然从闪存读取的字节数更少，但却需要更多的 CPU 来处理 I/O ，这是一个潜在的制约因素。
>> 2. 在没有任何负载的系统上，有些 I/O 变化在人为基准条件下不会出现任何问题，但在具有真实负载（如 Nexus 6 上的加密）的实际用例中有时则会出现问题。
>> 3. 在某些方面，基准化分析显示回归率达到 85%。
>> 随着 SquashFS 日趋成熟并且增加了旨在降低 CPU 影响的功能（例如，将不应压缩且经常访问的文件列入白名单），我们将继续对其进行评估并向设备制造商提供建议。
>> 链接：[常见问题解答  |  Android 开源项目  |  Android Open Source Project]( https://source.android.google.cn/devices/tech/ota/ab/ab_faqs)
> 如果压缩是以性能急剧下降为代价的，那其实还是得不偿失的，所以对于性能的测试就是关键点。

ref: https://zhuanlan.zhihu.com/p/264923041

@Buges #7 同等压缩下更快读（相对于 ext4 ，毕竟之前的 system 使用的是 只读的 ext4 ）
squashfs 似乎缺乏压缩

@anguiao #3 已经准备上了

早就习惯 system 只读了，反正全靠 magisk 修改内容

@Buges #1 华为和阿里主导的，应该有优势在的，不然不会被选为 Android 13 的强制特性的。

@HashV2 #25 还在，补正 QQ 数据库里的歌曲的话先选本地歌曲让他识别到，然后歌曲信息里有上传到微云的选项。
最近经常这么做，就算官方版权寄了还有自己微云的一份

@TrevorPhillips #9 酷基找找吧，只是听到这个消息

iqoo/vivo 最近有工具
pooc （小米海外）
Google

在多人的情况下（接入容量需求大）：AC+AP > Mesh > 室分

不能打开多个工作区，但远程窗口可以打开本地文件

@Horance #81 V2 应该是不能删除帖子的，除非涉及隐私问题之类的