@Material3600 可以试试 netsh int ipv6 set disabled 或 Powershell Get-NetAdapterBinding -ComponentID ms_tcpip6 等等.

直播一般关键帧间隔比较短.

@cr3bit 就我印象中记得的是, 运营商基本都有粗略的行为识别, 可能是出于监管原因, 至少可以识别到:
1. 传入/传出 方向;
2. 服务域名/类型/端口 (HTTP/HTTPS/BT or PT/TCP/UDP, 可能还涉及到其它具体的应用);
3. 发起及持续时间;
4. 持续流量大小;

有点类似于流量计费, 印象中, 以前是不是有这种流量计费的宽带模式?

所以, PCDN 的特征是很明确的: 传出 (上行) 方向, PCDN 服务方特定域名 (在部分文件中也出现过), HTTP/HTTPS 类型, 高位端口 (可能).

@Jirajine 只要大部分用户是属于正常行为模式, 那么小部分用户属于可以容许和调控的范围. 运营商在出售带宽的时候也并没保证其可以一直跑满 (特别是无高峰期保证), 通过 QoS 等技术可以实现优先级控制, 在带宽饱和的情况下优先保证高服务质量要求的应用运作. PCDN 属于盈利性服务, 家宽是不允许用于盈利服务的, 这其中还涉及到一个备案的问题, 而 BT/PT 并不是盈利性服务, 即后者是事实上并没什么关系但被一刀切波及的.

@littlecap
1. 高上传高下载在总体一直是有占比的, 运营商一直在控制这个比例来进行调控和超卖, 运营商不会拒绝将剩下的带宽冗余特别是几乎不要钱的下行提供给有需要的用户让自己的收入更高, 特别是带宽占用是因片区而异的;
2. 上下比例是有各种各样的 来源 / 消息 / 文件 确定的, 且这也是最简单判断的一刀切方法;
3. 运营商有合法且方便的理由拒绝用户进行 PCDN, 但并没有合法且方便的理由拒绝用户进行 BT/PT 下载及上传, 尽管很多用户使用 BT/PT 下载不合法的版权内容, 但前提是运营商有及愿意进一步的具体审计这些内容, 但犯不着;

纵观历史, 限制政策一直是随着 PCDN 而非 BT/PT 而同步, BT/PT 用户的误封也有 申诉 / 保证书 解除案例, 可充分证明你说的是错的.

用户习惯问题, 且分区而非分文件夹可能有助于降低误操作率.
现在也有这种情况, 不过不分区占比相对也大了一些, 原因是多磁盘自带多分区属性 (在所有磁盘上).

行为识别比一刀切更有效, 用户有持续跑满上传带宽的权利.
BTW: 尽管虽然但是还有跑 Hentai@Home 这种 PCDN 的...

@Jirajine 这是无奈之举, 因为 qBittorrent 作为 upstream 发起 Issue 要求更改, 同时用户这么用也具有被不允许的 PT ban 的风险.

@iseki 无论如何, 让我们看看 Apple 对此的回应和态度.
做出这种“无缘无故”的更改, 肯定是有其理由在. 我只能推测最大的可能性是基于安全相关的理由.

@iseki 引用: https://zhuanlan.zhihu.com/p/346722474
1. SIGSEGV 并没有严格定义, 在 Linux 中, 有一个要求: 内存访问的目标在程序可以访问的用户态地址空间;
2. 早在 2020 年, 就有人指出 macOS 并不完全正确的实现了 POSIX 兼容, 如 https://stackoverflow.com/a/56674321. 其原因不难理解, BSD/XNU/Darwin 可能是 POSIX 兼容的, 但我想 macOS 可以并不一定是;

想起来那个笑话, 最好把验证用户密码是否正确也放到前端.
我就问几点: 在前端做所谓的加密怎么让用户无法绕过密码规则验证? 怎么防止用户的无效构造数据? 通过 RSA 在 HTTPS 的基础上对数据进行**重复**验证对性能的影响和意义?

因为这个音质我已经把一对 HomePod 出了, 感觉省了不少钱, 而且环绕声效果还更好...

我重新看了看这个文档:
These crashes are **most often** identified by the EXC_BAD_ACCESS (SIGSEGV) or EXC_BAD_ACCESS (SIGBUS) exceptions in the **crash report**
所以 Apple 并不保证这个信号一定是两者中的其中之一, 但又说的很隐晦...

即, 未担保的方法/接口 显然是可以改动的, 但在改动之前, 应该先进行小范围/大范围测试, 而不是直接推到正式版上, 利用这种未担保特性显然是程序本身的问题, 但如果这种未担保特性的影响特别广泛, 那么测试有助于提前解决问题.

@Rorysky 合理了.
不用担保的 API 或特性去产生的任何行为都不应该被视为可靠的, 利用这种特性去做的程序本身也是不可靠的, 只不过这个不可靠性取决于上游 (也就是 Apple).
大家都用 **不等于** 这么用正确.

不过 Apple 在 Dev 不改甚至 RC 不改, 却在正式版改, 太激进了, 这样的发布策略并不合理.

电量校正的话, 为了获得尽可能大的容量数值, 一般是从 100% 放到 0% 作循环, 放的少了可能会影响“检测到的”最大容量, 但检测和实际是两码事.

@rednose1037 看起来和 Asahi Linux 的硬编码值差不多, 低于 75% 开始充电, 高于或等于 80% 停止充电. 嗯, 所以如果用户刚好落入在这个区间上充电, 会无法充入.
我将我的守护进程改为了 78-80% 的区间, 因为我觉得 75% 还是低了点.

我不关心, 所以一直不校准, 现在 440 次循环电池 85%, 感觉还行.

@rednose1037 原始方法就我实际测试是不充电, 放电后在 76% 下做的测试, 插入充电器后观察不到充电.
可能和楼上所说是有个区间吧, 我主要还是希望控制 LED.