@qiubangzhu 限度 1M/s 确定不是你服务器的问题，日常使用体验绝不止这个速度，腾讯云可用腾讯镜像内网地址。

刚刚用 termux 的 apt 更新，本来用的清华源，提示校验不通过，换成阿里的又好了，经常这样，之前路由器上 openwrt 用的腾讯源偶尔抽风就换清华源。总有几天抽风的时候几个轮着换。

题外话，termux 内置的 termux-change-repo 里面，一半的镜像源竟然都是国内的。（→_→也有可能是官方源套了 Cloudflare ，海外体验太好没有动力建镜像站）

国内阿里、腾讯、华为 3 选一，没纠结过非得哪个最快，速度都挺满意。
NTP 也是用的阿里、腾讯。

线路不行啥协议都无解，本地和 OneDrive 同步，远程和 OneDrive 同步。
其它云盘一样。

@bsfmig #14
“Red Hat Enterprise Linux 8 删除了 Btrfs 文件系统。……
……我个人认为，群晖现在就大规模使用 btrfs ，一定程度上是对用户的不负责任。”

这个观点我不敢苟同，红帽是否支持 Btrfs 并不能说明此文件系统的好坏与否，更无法因为红帽不支持而群晖使用得出群晖不负责任。
同样的 SUSE 也默认使用 Btrfs ，是否能得出 SUSE 也对用户不负责任呢，还是说因为 SUSE 选择了就能说明可靠呢。
开源世界最怕的就是以某个商业公司的行为作为权威，可靠与否依靠的是测试数据，而不是某个商业公司的选择。

不禁让我想起了那个段子：
安卓手机打开一个 APP 卡顿，“安卓真垃圾”
苹果手机打开一个 APP 卡顿，“APP 真垃圾”

@bclerdx 绑定国内银行的万事达卡，账单地址在国内，然后就会锁定国区（不受 IP 影响）。
缺点嘛就是很多 APP 没在国区上架，且部分 APP 推送更新比美区晚 1 周左右。
优点就是有些 APP 只在国区上了架，还有部分没在国区上架的含内购的 APP 可以白嫖内购功能不提示内购（有些 APP 的内购功能在没有 Play 框架的手机上不收费，有 Play 框架但是没在国区上架的 APP 相同效果）。

安卓 10+更新 Chrome 和 webview 前会先更新 120MiB 的 Trichrome Library ，如果后者没更新完前两者是不会更新的。
Trichrome Library 更新时只有通知栏一个进度条（如果没禁用通知的话），更新后无任何显示，之后再升级 Chrome/webview 版本也不会自动覆盖 /卸载旧版本（手机可用空间会一点点越来越少），目前只能通过 adb 卸载。
我的 Play 锁定的是国区，更新频率比美区晚一周左右。

谷歌翻译使用不同区域的 IP 翻译结果不同，谷歌翻译可能是谷歌中国站为数不多的几个能提供直连的服务之一。
日常体验 Chrome （谷歌翻译）、Edge （微软翻译）、360X （谷歌、有道、DeepL 不定）的网页翻译，还是 Chrome 的准确率更高。

建议先排除硬件再排除软件，如果是我我会选择 AIDA64 单烤 FPU ，同时观察 12V 供电（是否过 /欠压）和散热是否有问题。

@kgdb00 #8 我猜的啊，不一定准确。在 i386 那个比尔盖茨说“640KiB 内存对于任何人来说都足够了”的年代，zImage （有体积限制，大概几 MB ？）是满足需求的。
后来 x86 上的内核体积越来越大，单个 zImage 已经装不下了，就出了 bzImage 。类似硬盘上的分区表，也是经历了从 MBR 到 GPT 的转变。还有 BIOS 到 UEFI 也是一样，x86 的历史太长了，历史包袱太多。
大概在 2009 年时，x86 的内核体积早已经到了无论如何 zImage 都装不下了，内核就把 x86 对 zImage 的支持删掉了。

额，OP 的大前提理解是错误的：

“bzImage 本来就是为了方便内核能存储在嵌入式系统很小的 SPI 上”
>> 并不是，bzImage （ big zImage 意为“大的”zImage ，和 bzip2 没有关系），怎么会“大的”反而是为了在嵌入式上呢，bzImage 是当初专门为 x86 架构搞出来的东西。

下面以最新的主线内核来举例吧：
① [第 335 行：define archhelp
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
echo '* xipImage - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
echo ' uImage - U-Boot wrapped zImage'
echo ' bootpImage - Combined zImage and initial RAM disk'
来源： [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Makefile?h=v5.18-rc7#n335]
>> 可以看到在 ARM 上内核支持 zImage 、Image 、xipImage 、uImage 、bootpImage ，不支持 bzImage ，→_→那我要是手动指定 bzImage 会怎样？
[第 306 行：# Convert bzImage to zImage
bzImage: zImage]
来源： [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Makefile?h=v5.18-rc7#n306]
>> →_→会自动变成 zImage

② [第 207 行：define archhelp
echo '* Image.gz - Compressed kernel image (arch/$(ARCH)/boot/Image.gz)'
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)']
来源： [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Makefile?h=v5.18-rc7#n207]
>> 可以看到在 ARM64 上内核支持 Image.gz 、Image ，是不支持 zImage 和 bzImage 的，至于为啥不支持，可能是开发者觉得没必要，也可能是觉得这活儿交给 boot loader 够了，也可能是纯粹优先级太低没动力（懒）
与 x64&x86 一脉相承不同，ARM64 跟 ARM 的关系就和雷锋和雷峰塔的关系似的，跟 MIPS64 血缘关系更近

③ [第 299 行：define archhelp
echo '* bzImage - Compressed kernel image (arch/x86/boot/bzImage)']
来源： [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/Makefile?h=v5.18-rc7#n299]
>> 可以看到在 x86 上只支持 bzImage

④ 另外在内核文档这里也写了建议在 ARM64 上如需要使用压缩请使用 bootloaders 实现：
[第 58 行：3. Decompress the kernel image
------------------------------

Requirement: OPTIONAL

The AArch64 kernel does not currently provide a decompressor and
therefore requires decompression (gzip etc.) to be performed by the boot
loader if a compressed Image target (e.g. Image.gz) is used. For
bootloaders that do not implement this requirement, the uncompressed
Image target is available instead.]
来源： [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.rst?h=v5.18-rc7#n58]

我这暂无法复现，同用 360X 测试，打开 CCTV 直播出现上传的时间段占比很低，作为对比，我打开 B 站的比赛直播，可以观察到稳定且持续的上传。

@Chowe #17 根据最新的 Linux 主线提交记录，这时间没有半年吧。 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/ntfs3?h=v5.18-rc5]

@msg7086 #62 ，这个我已经在#48 描述的很明白了，“ ABI 稳定和软件运行稳定都是稳定版的必要不充分条件，没有哪个可以单独代指”。
你说的 [运行稳定就和「稳定版」里的稳定无关了] 是否有可参考的说法来源，或者是哪个发行版对此有过类似的描述？可以发出来。
发行版的稳定版分支既包含了对兼容性的要求，也包含了对运行稳定性的要求，以 Ubuntu 为例，在整个发布周期会经历α→β（ ABI 、界面冻结）→RC （内核功能冻结）→正式发布（这才是最终发布的稳定版分支）。
如果按照 ABI 、API 稳定来作为稳定版里稳定的要求，那 Ubuntu 完全可以直接正式发布β版作为“稳定版”就可以了，ABI 在该版本生命周期里已经 100%不会再更改了。但实际是从β→RC→最终的正式发布稳定版分支，整个阶段都是在进行运行稳定的修复工作。

@xQmQ #54 只要需求是硬件无关、内核无关，WSL1 也很爽，用来编译个 openwrt ，WSL1 完全没有问题。
至今没升级到 WSL2 ，Hyper-V 一开，麻烦事儿太多。

@msg7086 #44 ABI 稳定的“稳定”指的应该是“兼容”
一个软件的 ABI 稳定和软件运行稳定都是稳定版的必要不充分条件，没有哪个可以单独代指。
楼主这里的稳定语意上指代的必然是运行稳定。任何一个主流发行版在版本寿命支持期间（滚动发行不存在）必然是 ABI/API 兼容的，按理说除了α版存在 ABI/API 改动的情况外，从β/RC 开始，ABI/API 都应该保持兼容。

Fedora/Ubuntu 二选一
什么是“稳定”，一个软件在被经过充分的测试前，它是处于稳定 /不稳定的叠加态的，一旦它经过了充分的测试后就立刻被固定为稳定 /不稳定，所以可以用已知 /未知来代替稳定 /不稳定。
​一个发行版的稳定分支，理论上该分支收录的上游软件包也应该是稳定版的（不绝对，比如大量发行版的稳定分支甚至是 LTS 分支都默认包含过 grub2 的 beta 版本）。所以软件包新的发行版及时收录的新软件包从上游来看收录的就是稳定版，一堆稳定版的包凑一块是稳定还是不稳定呢？未经测试前不好说。
​目前 Debian 是上面传统思维的守门员之一，但现在越来越多的软件都没有一个稳定版之说，新版本修复了旧 bug 同时引入了新 bug/未经充分测试的新 beta 比旧稳定版更稳定的情况比比皆是，这就导致了 Debian 如果想保持老的模型就需要包维护者做大量的工作，当包维护者不够时就会出现人们说的 Debian“老”的情况。
​所以要想又稳定又新，需要这个发行版的社区一定够大（包维护者够多 /小白鼠够多），有点像 BT 下载，如果既想下载速度快又不想上传必然是不可持久的。
​几月前我在 Ubuntu 一次更新后，fish 遇到了问题，搜索后早已有人反馈给了包维护者，这个 bug 是由于安装了 fish 但没安装 snap 时导致的 fish 报错，包维护者也及时提供了临时解决方案但等源里的包正式更新就慢了。
​折中的方案就是选择一个固定周期发布的发行版，当源里提供的软件包版本不满足需求时，那就不用源里的呗，自己从上游获取手动安装。所以 Ubuntu 的 PPA 曾是个好东西，当然目前被 snap 之类的边缘化了。
PS.唉，一个软件能在千奇百怪的硬件环境下跑起来本身就已经是个奇迹了。奢求稳定，人生苦短，还是追求点更现实的吧。