@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.

@barra2k AIDente 的问题是: 1. 免费版不能控制 Magsafe LED; 2. 利用的不是固件特性;
不过听说他们也在评估这个新功能了.

粗看感觉挺不错的.

https://d.loli.wiki/lslqtz/bclm.zip
如果你敢用未知来源的二进制文件, 可以试试用这份替换 homebrew 安装的 /opt/homebrew/bin/bclm.
在替换之后, 用 bclm unpersist 删除原来的一次性保持法, 然后用 bclm persist-loop 加入新的守护进程保持法.

猜测: 系统通过 CHWA 去控制的不仅仅是保持 80% 行为, 可能还控制了充电行为, 而 bclm 原有的一次性保持法使 CHWA 一直为 1, 进而固件会持续的阻止充电.

https://github.com/zackelia/bclm/pull/39
我选择用守护进程解决问题, 还顺带解决了 Magsafe LED 灯不变的问题. 这段时间测试下来没什么问题.