@Awes0me #121 那不就得了？一定要一拉一踩有什么用呢？

@Awes0me 你只看到了这一个软件，附带了一大堆存在 github 的傻瓜脚本就觉得 iOS 无敌了跟安卓差距天大了。那你知道 Xposed 在停更前仓库有近百个模块一键安装随用随开，iOS 实现同样的功能必须得越个狱，还要等别人发漏洞用个低版本系统一两年不敢升级，你能意识到这个差距有多大嘛？

系统封闭和开放的特性造就了不同的软件群，你一定要关公战秦琼有什么用呢？一定要无视安卓生态的优势、拿苹果占上风的点去打安卓的劣势？两个都买择优用不就好了，是经济能力的差距不允许安卓和苹果双持嘛？

@chanChristin
1) 你 iOS 一个软件能解决这么多问题，是因为你需要在 iOS 上解决那么多问题而被动整合成了一个软件，而不是你一个软件的设计目的就是解决那么多问题，而 Quantumult 和 Quantumult X 都是模仿者，因而存在同用途多竞品的情况。如果你要拧这个概念，我可以给你举出一堆 “为什么安卓上的各种 xx 软件（比如 ‘一个木函’） iOS 要拆成十几个软件” 的例子。

2) 找对应版本和刷模块并不麻烦，甚至好些模块已经可以无视版本了。而存在版本对抗本质上是安卓存在更自由、更无约束的软件环境和技术环境。如果你觉得麻烦，那恰恰说明 iOS 的局限性使其被迫通过各种合法途径提供运行环境（可执行脚步的软件本身），并一并提供封装好的脚本来达成同样的目的，方式傻瓜的同时也可怜。

3) 定时跑签到本质是“抓包 - 解包 - 修改报文 - 重发请求” 的处理流程，或手动、或通过脚本自动，你为什么觉得 HTTP Canary 做不到呢？我还以为你会有基本的技术概念，现在只希望你的动手能力没有被傻瓜工具劣化了。

@chanChristin #70 如果是翻墙代理，那软件有很多；如果是去广告或解锁特定功能，几乎主流软件都有破解版或 XP/Magisk 模块，不需要多此一举；如果是 MITM ，有 Http Canary 。

1) 识别率极差，侧躺基本不成功，早上睡眼朦胧基本不成功，趴在枕头上基本不成功，做菜放在桌面上我得特意把脸凑去过才能成功
> FaceID 会根据识别结果（识别失败后用户手动开锁）来学习外貌，进而提高识别率和速度。FaceID 需要完整的面部 3D 信息，如果遮挡面太大会直接失败。如果你长期有半遮面开锁的需求，建议录入口罩 ID ，同时盖住鼻子以下的部位。

2) 极度考验我拿手机的姿势，手指头得从最下面划上来，我拿上面不行（为啥不能改成安卓那种从哪往上扒拉都能开锁的设计呢）
> 因为这是苹果的全局操作逻辑，即 “任何有 ‘白条’ 的地方，都是可以拖动的”。且手指位于半屏滑动会跟侧滑相机、上下滑展开/收起通知冲突。而且这个冲突逻辑是因为这些操作都是在 “白条必可滑” 的基础逻辑上建立的，而并非平级的逻辑冲突。


3) 既然我都得扒拉那一下，为啥我不按个指纹呢，不太理解这个扒拉的逻辑
> 如果你对指纹情有独钟，你可以购买 iPhone 8 或 iPhone SE 机型。iPhone 在解锁后需要再次滑动，是因为通知中心/锁屏的展示和 mask 逻辑与安卓不一致。安卓长久以来没有在锁屏 mask 掉通知的逻辑（我知道现在有），因此苹果为了 adopt 这个 mask 和 unmask 的逻辑，需要在这里多一层校验（亮屏解锁，但不进入主屏幕），允许你预览 mask 掉的通知内容以及主屏幕信息，比如用药提醒、个人日程等 —— 没错，苹果认为你的用药数据和今日要做的事也属于需要 masked 的隐私。而安卓在指纹识别机型上通常是 “亮屏 - 解锁 - 进入主屏幕” 并为一次性操作（或提供独立的跳过解锁开关），因此没有这个 “扒拉那一下” 的逻辑，锁屏通知只有预览逻辑，没有 mask / unmask 逻辑。

4)发这些是希望，iPhone 用户跳出他们的圈子，看看外面是啥样了。。。。
> 用 iPhone 的并非没有安卓，那是因为什么促使安卓用户换到 iPhone 或把 iPhone 当主力机型的呢，有想过吗？

5)躺着不行，侧躺不行，趴着不行，手机平放桌面上不行，睡眼朦胧不行
> 躺着可以，只要露出足够识别范围的完整面部，包括侧躺也可以；趴着可能是距离过近，Face ID 有最小识别距离（约 10 厘米），太近了会导致红外没法完整铺开在面部，采样信息不足；手机平放在桌面可以，且无需正摆，360 度各种角度都可以识别（仅限 iPhone 13 及更新到 iOS16 以上支持了横屏解锁的机型）；睡眼朦胧是因为睁眼不够大，或者可能你的眼睛比较小，没有获取到足够的瞳孔信息。FaceID 验证很重要的一点就是要求睁眼，且正视屏幕，目的是抵御在机主在非自主情况下的解锁攻击行为。

锁屏 widget 的 app 有自定义显示日历的，AppStore 装一个。

1) 跨区跨账号下载软件，如果每次新装软件不想手动换区（因为会丢 AM 资料库），可以用爱思助手。
2) 应用语言可以在设置中的 “首选语言” 里单独设置。如果没有该选项，请升级至 iOS 16
3) AppStore 的页面无论什么区，都已经统一了多语言自适应，全界面汉化，但人工录入的文本除外（比如 “编辑推荐” 里的推荐词）。如果看不到中文，请升级至 iOS15

按照 OSI 七层模型，MAC 地址仅在数据链路层会被调用（ 2 层），TCP 封包工作在传输层（ 4 层）。TCP 包头不记录 MAC 数据，GFW 高深但也不是魔法，没可能突破现实世界的代码束缚。https://i.imgur.com/5IJIkTr.png

@IdJoel #28 V2EX 用户特有的不看需求无脑推苹果产品。

建议这位眼高手低的 mac 爱好者先从 “学习在 Windows 下使用命令行下载 Youtube 视频” 开始： https://v2ex.com/t/1015380#reply14

@CNM47589 #39 楽，急了🤣👉

b64 都不会转的 mac "爱好者"，我不好评价

@justdoit123 #8 “无状态” 与 “有状态” 的通俗区别是，该应用的数据是否会因为应用退出而被删除。因为有状态应用的数据、配置、程序自身三者高度绑定（但目前 Cloud Native 的势头已经对这个情况大幅优化了）。

比如常见的 K8S 场景：Kafka 需要外挂数据卷，而 K8S Admin 选择分配 HostPath 的方式，那么 Kafka 的数据目录中的 properties 文件会包含 BrokerID 。如果有状态应用被 reschedule 了，很可能会导致 Broker-0 被分配到先前 Broker-3 的所在节点上，导致 BrokerID 读取不吻合，导致错误退出。

Stateful 在水平扩展时需要保证数据目录被妥当创建，同时程序或配置里要存在 “初始化新节点” 的逻辑，并且当服务节点宕机、迁移时要有完善的节点退出或数据重用逻辑（比如上面提到的 BrokerID 读取问题，以及 Galera Cluster 的数据落盘保证机制），这些数据与程序的硬绑定逻辑会让有状态应用比无状态应用更难随意调度。

@ryanking8215 #6 如果你问我的话，是，但与 Bitnami 无关。Kafka 有脱离 ZK 运行的 Raft 模式，而且最小只需要单个节点。

插一嘴，现在 kafka 已经无需依赖 zk 来托管 broker 信息了喔

刚测试了一下，没有复现，两者方向一致。

iPhone 15 PM + Watch S7

纯钛大概 180 就有了，但通常不建议买纯钛，β 钛刚性更好，纯钛容易变形。β 钛大约 80 块钱就有了，可以去阿里巴巴找万年龟的版型。