虽然但是，束缚数、支配集、专业学科、内容提交，这几样要么复杂要么麻烦，普通程序员面对这些事如同受虐，能感到爽的只有受虐狂吧

想知道一件事，交叉编译的时候，是不是能自动处理目标平台的特有调用？

例如 boost-asio ，在 Windows 用 IOCP ，在 BSD 和 mac 用 kqueue ，在 Linux 用 epoll ，交叉编译的时候能够正确使用系统调用吧？

撞名了： https://mcpp.sourceforge.net/

@hefish 自己开运营商也没用，那反而更加要 100%执行 GSMA TS 43 流程

而我正是非常不爽 GSMA TS 43 这么死板的认证流程，它根本不提供离线转移 eSIM 的选择

@docx 双卡槽好办，如果用的是实体卡+eSIM 手机（数量正越来越多）就有点，怎么说呢，重复多余？ eSIM+eSIM

@hefish 有鬼用咩，GSMA TS 43 流程不改，像 Holafly 这样的运营商照样限制死

@aqc113 我的索尼手机用着联通卡，每次都没事，想不到三星反倒不行

@sddyzm 问题是处理起来就没法一样，需要新 header 、各种设备需要大改，要不然根本没法用

而且地址空间比 IPv6 小一半，这可就算不上什么优化了，3L 和 8L 也提到过

@sddyzm 这种改法也就易于人类理解，兼容性一样只利于人类兼容
对于二进制世界而言，实际上是做不到兼容的（我在第三部份已经举例了）

UDP 测速可以试试 http3 ，不一定要用 iperf

补充：最后一行还有个 8K 编码，但只有 AV1 这个编码类型

571 mp4 7680x4320 60 │ 1.04GiB 27064k https │ av01.0.17M.08 27064k video only 4320p60, mp4_dash

文件大小接近于前面 4K VP9 ，仅仅是大几十 MiB

漏了一个更重要的参数：编码格式

单论 youtube ，这个平台支持 H264 、AV1 和 VP9 ，对于 2.5K 、4K 及更高分辨率的视频并不使用 H264 ，只会使用 AV1 和 VP9 。

就以这个视频为例：

https://www.youtube.com/watch?v=G5RpJwCJDqc

使用命令行查看编码和码率
yt-dlp -F "https://www.youtube.com/ watch?v=G5RpJwCJDqc"
（ URL 中的空格自行去掉）

最后 4 行是这样的：

308 webm 2560x1440 60 │ 424.59MiB 10798k https │ vp9 10798k video only 1440p60, webm_dash
400 mp4 2560x1440 60 │ 242.05MiB 6156k https │ av01.0.12M.08 6156k video only 1440p60, mp4_dash
315 webm 3840x2160 60 │ 965.87MiB 24564k https │ vp9 24564k video only 2160p60, webm_dash
401 mp4 3840x2160 60 │ 496.68MiB 12631k https │ av01.0.13M.08 12631k video only 2160p60, mp4_dash

可见 VP9 的码率、文件大小都比 AV1 的高得多，接近乘 2 了

Transmission 的 preallocation 要自己手动改 settings.json

https://github.com/transmission/transmission/blob/main/docs/Editing-Configuration-Files.md

如果 GUI 有相应选项，要看清楚选项内容，因为 Transmission 的预分配模式有 3 个（关闭、快速、完整）。

不用 qBittorrent 的话，还可以选择 Transmission

应该是旧版 qbittorrent 的 bug ，早在 2023 年就有人在 GitHub 提了 issue:
https://github.com/qbittorrent/qBittorrent/issues/19410

具体可以看一看“HDD + LINUX + NTFS + NO-PREALLOCATE”以及“HDD + LINUX + NTFS + DO-PREALLOCATE”的部分，以及后面那一两层楼。

原作者的描述是，在 Linux 环境无论是否选择预分配，qbittorrent 都会预分配。

按照这个 issue 底部的 comment ，升级到 qBittorrent 5.0.4 应该就行。

2038 问题由工具链兜底实在是强人所难了，毕竟作用很有限。即使工具链给了 64 位 time_t 在内部做转换，到了 OS 层面给出的时间直接就是错的，工具链再怎么兜底都没用。这就好比寄信人提供的门牌号直接就是错的，就算印门牌号的纸足够容纳都没用。

MinGW 那边可以认为是没人搞，长期以来进度缓慢，无解

这个有折中做法，chcp 65001 即可解决。也可以主动调用 SetConsoleCP 和 SetConsoleOutputCP 。

Android 的事情，老实说，那得看 Google 的脸色了。编译器开发者或许能够解决二进制文件生成的支持，但 SDK 的更新就无能为力了。若 Google 决定停止向旧版系统提供新版 SDK （无论 C/C++还是 Java/Kotlin ），无论给多少钱都不行，那也不可能拿起武器对准 Google 大楼要求他们继续更新的吧。这个责任，不是某一个编程语言能够承担的。除了 Google 自己，其他人拿它没办法。顶多只能靠开源社区自己打 patch 做更新。
打个比方，这就相当于要求在 Linux 4.x 使用 io_uring 的 API ，编译时发现不存在然后责怪编程语言和工具链，属于怪错对象了。想要用不是不行，这得有人愿意做 backport ，但这显然不是编程语言和工具链的责任了。