jjpprrrr 最近的时间轴更新
jjpprrrr
ONLINE

jjpprrrr

V2EX 第 346487 号会员,加入于 2018-09-02 16:28:07 +08:00
今日活跃度排名 1467
jjpprrrr 最近回复了
86 天前
回复了 airbotgo 创建的主题 问与答 如何判断某个类原生系统的质量?
@Buges #7 想法很好,但是过于理想主义了。对于认真维护 ROM 的人,每天都刷好多个版本,还经常一不小心某个改动导致启动不了了,或者 /data 出问题了,最后全得格式化重来。你觉得在这种情况下,怎么可能把这台机器作为主力来使用?所以实际情况往往恰好相反,真正靠谱的都不会把开发机器作为主力,这样才能毫无顾忌的去尝试新东西,遇到用户反馈的问题也能及时的按步骤去复现。

举个例子,假设用户告诉你,当前这个版本在系统初始设置的时候,录入指纹会崩溃,你怎么办?如果手机上有你当前几十上百 G 的数据,你是根本不可能去全都格式化掉,自己亲自测试系统初始设置。

相反,大量依赖别人的工作的人,才会放心大胆的把设备当作主力来用,因为他 cherry-pick 的东西都是别人那里来的,别人都测试过的,大概率是可以直接拿来用的,没有什么试错的成本。
87 天前
回复了 airbotgo 创建的主题 问与答 如何判断某个类原生系统的质量?
非常好的问题。先声明一下,我是 PE 核心组成员,目前维护 Mi 11 和 Mix 2s 。作为一个圈内人,我当然会有一定的偏见,但是我会尽量客观的说一下我的看法。

1. 维护者的负责任程度是非常难以判断的,不过可以去观察一下他对于用户的反馈是否及时回复,在 XDA 或者 telegram 上是否活跃,在与用户交流的时候是否能够理性的承认存在问题的可能性,并礼貌的要求提供复现的步骤或者提交日志。

维护者的技术水平,我个人认为作为一个普通用户是很难判断的。我自己在维护两个型号,并且经常审核一些 PE 收到的官方维护者申请,见得多了,自然看一眼 GitHub repo 就知道这个人是真的有水平还是只是 cherry-pick 别人的东西。如果你是一个普通用户,那可以去翻翻维护者的 device 和 kernel repo ,看看有多少是他自己原创的 commit ,有多少是 cherry-pick 别人的东西。这里并不是说 cherry-pick 不好,开源社区里面,使用别人的 commit 的时候保留原作者信息是很重要的。我的意思是,如果他永远在用别人的东西,自己不尝试做一些修复或改进,那大概率这个人水平并不怎么样。原创 commit 也要看是什么样的 commit ,是在实现一些新功能,还是只是改个版本号,更新个 proprietary blobs 之类的。

2. 由于存在利益冲突,我就不推荐了。

3. 从我个人的观察来看,LineageOS, Pixel Experience, Paranoid Android, ArrowOS 普遍来讲都相对靠谱一些。当然可能还有其他的团队也不错,不过我也不是所有的都了解。
88 天前
回复了 DianQK 创建的主题 Linux 我的 Arch Linux 和 LineageOS 使用心得
@DianQK #22 并不是 kernel 故意关掉了 wireguard 。Linux 5.6 的时候 wireguard 才正式进入 mainline ,在这之前的版本是没有 wireguard 的,需要维护者在 kernel 内手动添加 wireguard 为旧版本 kernel 做的 backport 。如果维护者没添加,那自然就没有……
理论上可以自己编译一个 CarrierConfig 的 rro overlay ,把对应运营商的 carrier_vt_available_bool 之类的关掉?
@dzyou2007 #8 微信指纹支付用的是 soter 那一套东西,跟支付宝不一样
@ysc3839 #6 看起来 IFAA 只是一个接口,依赖不依赖 TEE 还是看你设备本身指纹的实现吧
支付宝指纹需要设备上编译或者添加了 IFAA Manager ,我维护的 PE 都可以直接用支付宝指纹的
234 天前
回复了 wdssmq 创建的主题 全球工单系统 百度密码限制最长 14 位,差评一下!
@whileFalse #9 如果有完整的谷歌套件的话,android 也可以自动记忆和填充 app 密码
263 天前
回复了 tediorelee 创建的主题 问与答 好哥哥们推荐一个自建音乐库的方案?
@LaCAfJH #25 不清楚,没用过 Airsonic
这个标题其实不太准确,GKI 说实话只是强制 vendor 把所有改动都模块化,使用谷歌弄出来的统一的 KMI (Kernel Module Interface) 接口挂载。

KMI 的一个问题就是,为了保证 vendor 的内核模块能正常挂载,KMI 必须保持稳定。这就导致了一个问题,linux 主线内核是没有维持 KMI 不变这个要求的,所以在谷歌的 GKI 内核里,一些情况下主线和上游的补丁如果不小心造成了 KMI 的改变,反而不能直接合并,必须用别的方式移植或者魔改,这个问题谷歌在去年的 LPC 会议上也提到了。从这个层面来说,GKI 反而离上游更远了,因为 vendor 是面对 KMI 开发,而不是想办法把自己的改动直接合并进上游主线。

对于 vendor 来说,一切开发的目的都是为了发布和更新产品,所以只要谷歌不强制 vendor 去把改动合并入上游 linux 内核,vendor 自己是没有动力去做这件事的。的确,GKI 从某种意义上,至少避免了很多 vendor 魔改通用的内核部分代码,让大家都用同一套 GKI 的东西。但是,我个人觉得这种事情意义有限。GKI 其实是 Treble 的一种延申,Treble 把 system 和 vendor 分离,搞出了 GSI (Generic System Image),并且通过 VTS/CTS 之类的让 vendor 的东西“理论上”能启动 GSI 。但是从 Oreo 到现在三四年过去了,也没有哪个 vendor 会真正在发布的产品内用 GSI,我记得之前小米的工程师也抱怨过,升级大版本,说好的 Treble 的一些接口不变,该重新写代码还是要重写写。只要谷歌还在对 vendor 做类似的妥协,GKI 内核几年后也会是这个样子。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4183 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 07:45 · PVG 15:45 · LAX 00:45 · JFK 03:45
Developed with CodeLauncher
♥ Do have faith in what you're doing.