lslqtz 最近的时间轴更新
lslqtz

lslqtz

V2EX 第 152083 号会员,加入于 2015-12-19 16:19:27 +08:00
今日活跃度排名 29095
1 G 56 S 90 B
根据 lslqtz 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
lslqtz 最近回复了
@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 不改, 却在正式版改, 太激进了, 这样的发布策略并不合理.
10 天前
回复了 rednose1037 创建的主题 macOS bclm 并不能保持在 80?
电量校正的话, 为了获得尽可能大的容量数值, 一般是从 100% 放到 0% 作循环, 放的少了可能会影响“检测到的”最大容量, 但检测和实际是两码事.
10 天前
回复了 rednose1037 创建的主题 macOS bclm 并不能保持在 80?
@rednose1037 看起来和 Asahi Linux 的硬编码值差不多, 低于 75% 开始充电, 高于或等于 80% 停止充电. 嗯, 所以如果用户刚好落入在这个区间上充电, 会无法充入.
我将我的守护进程改为了 78-80% 的区间, 因为我觉得 75% 还是低了点.
10 天前
回复了 tryqtyl 创建的主题 Apple macbook 使用 bclm 后是否需要定期校正电池容量
我不关心, 所以一直不校准, 现在 440 次循环电池 85%, 感觉还行.
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2843 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 275ms · UTC 15:23 · PVG 23:23 · LAX 08:23 · JFK 11:23
Developed with CodeLauncher
♥ Do have faith in what you're doing.