V2EX › lslqtz 的所有回复 › 第 7 页 / 共 243 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 3 4 5 6 7 8 9 10 11 12 ... 243

❮

❯

242 天前

回复了 drymonfidelia 创建的主题 › Windows › 为什么 Windows Xp~Windows 7 时代，很多人习惯电脑分 4~5 个区？机械硬盘系统和数据在同盘不同区不是会大幅提升寻道时间吗？ SSD 分 2 个区我还能理解，重装系统不需要格式化整块硬盘。

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

243 天前

回复了 studyingss 创建的主题 › NAS › 为了应对运营商考核上下行比率，恩山无线论坛用户和某云盘使用恶意软件从 Bittorrent 网络无限吸血以提高下载量

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

243 天前

回复了 studyingss 创建的主题 › NAS › 为了应对运营商考核上下行比率，恩山无线论坛用户和某云盘使用恶意软件从 Bittorrent 网络无限吸血以提高下载量

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

254 天前

回复了 codehz 创建的主题 › Apple › Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4

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

254 天前

回复了 codehz 创建的主题 › Apple › Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4

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

258 天前

回复了 userKamtao 创建的主题 › 程序员 › 盼大佬解答，前端加密到底是不是脱裤子放屁？

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

259 天前

回复了 isAK47 创建的主题 › MacBook Pro › 被苹果 MBP 16 寸的音质震撼到了，有没有类似这种音质的小音箱，或者这种喇叭哪里可以买到？

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

261 天前

回复了 codehz 创建的主题 › Apple › Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4

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

261 天前

回复了 codehz 创建的主题 › Apple › Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4

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

261 天前

回复了 codehz 创建的主题 › Apple › Java 、Idea、Android Studio 用户请暂缓升级到 macOS 14.4

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

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

261 天前

回复了 rednose1037 创建的主题 › macOS › bclm 并不能保持在 80？

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

261 天前

回复了 rednose1037 创建的主题 › macOS › bclm 并不能保持在 80？

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

261 天前

回复了 tryqtyl 创建的主题 › Apple › macbook 使用 bclm 后是否需要定期校正电池容量

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

261 天前

回复了 rednose1037 创建的主题 › macOS › bclm 并不能保持在 80？

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

262 天前

回复了 rednose1037 创建的主题 › macOS › bclm 并不能保持在 80？

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

262 天前

回复了 jinininx 创建的主题 › Node.js › [NodeJs 全面解析] 全 48 个模块、4130 个函数详细解析！小白也能学会！

粗看感觉挺不错的.

262 天前

回复了 rednose1037 创建的主题 › macOS › bclm 并不能保持在 80？

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

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

262 天前

回复了 rednose1037 创建的主题 › macOS › bclm 并不能保持在 80？

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

262 天前

回复了 Ruttel 创建的主题 › Apple › Mbp 2021 14 风扇问题故障求助

既然官方同意检修, 那就说明这个机器是可靠的, 没有经过维修过的 (或者只是 Apple 看不出来), 所以没太大必要担心.
继续走售后吧.

262 天前

回复了 Kroos 创建的主题 › Apple › macbook 新人想请教一些问题。

(因为有沙盒, 所以 App Store 的应用可能会少一些或可缺或不可缺的功能)

1 ... 3 4 5 6 7 8 9 10 11 12 ... 243

❮

❯