@Themyth 楼主你两年前的是 128G 还是更大的硬盘？

如果也是 128G，那么“这硬盘比我两年前的还慢”是合理的。如果是更大的话就不太好说了。

@stoneabc wp 的 YouTube 是微软自己开发的，而 Google 强迫 wp 用网页版的 YouTube，于是微软心生不满自己搞了一个，并号称不影响 YouTube 的广告投放之类。

结果，Google 使用技术手段阻止了微软开发的 YouTube。

其实，微软还开发过版本的 ttaaoobbaaoo

@nodwang
“?当你的输入法没有 锦鲤、杠精、佛系、官宣、土味情话、皮一下、微服务、微博、腾讯、今日头条、字节跳动、、、这些词组,你会继续用么”

我的屁股是在拼音输入法这边，认为五笔会慢慢淘汰，但这个过程不会硬着陆。

但上述提问还是可以应一下：

我不用这些令人烦心的国内厂商出的输入法。
现在用 Windows 自带的输入法与 gboard，前者的词库还好，后者的词库烂到楼主给的 11 个词里只有 8 个能自动联想到。

可是这样可以不用国产的垃圾输入法呀。

firefox 与某些 chrome 的变体（开启了 Webextensionapi 扩展的支持），它们可以使用 ublock origin，adguard，adblock plus 等内容拦截器。

这两种限 Android。

iOS 的话 safari 自带内容过滤器引擎，但过滤规则需要从 Apple appstore 安装，并且条目数量有很强的限制。

@xiaoyang7545 把腿锯了是个好办法

@CloudnuY
有的雾灯把切线做的很好就没问题，这类雾灯纯粹就是一个配光更近更宽的近光灯，这类灯什么时候开着都不会影响他人。
实际上此类雾灯有时候还真的会成为近光灯的一部分，特别是它做成矩阵灯形式的情况下（可以根据情况开启全部或一部分）。

还有一种雾灯（通常是反射碗+卤素灯）没做切线简直和远光灯一样就很无解。这一类就只能在应当使用雾灯的时候开启。

@dxgfalcongbit
奥迪没有锅，我是这么理解的：

0，奥迪车的日行灯和其他牌子的日行灯的 behavior 没有区别。

1，开车的人有责任在晚上或照明不好的时候开大灯（近光或近光+远光），这个时候日行灯会降低 90%的亮度而作为示宽灯使用，此时没有眩光问题。

2，如果搭配自动大灯功能，那么近光灯会自动开启，日行灯自然也联动了。

3，最不济的情况下，某些车允许禁用日行灯。

其它：照明条件良好的夜间也需要开近光的目的不是为了你看路（路灯可能已经做得很好了），而是为了别的道路使用者能恰到好处地看到你的车：后面的需要看到你车的（红色）示宽灯乃至后雾灯，而前方的要看到你车的前照灯（近光灯），但又不能太亮（眩光）影响他们的视线。

另外欧洲的车厂搞什么随动大灯（用于远光模式的部分），甚至后面的矩阵灯都是为了在不影响别人的情况下尽量增强路面照明。辅助远光灯也是这个道理，它只能由车载电脑根据摄像头的数据决定开启时机。

@dxgfalcongbit 日行灯是不能在夜间开的，它的功率非常大，一般来说有 10W 的程度，可以说不亚于远光灯。
它的配光和远光灯一样都是照正前方，但光束散很多，这就导致日行灯的眩光远远大于近光灯。

当开启近光灯时，一般会把它的亮度通过 pwm 等方式降低到十分之一，这个亮度才适合用于夜间的示宽灯 /驻车灯。

所以在夜间使用日行灯（很多时候相当于不开近光灯）是迷惑行为。

@Eytoyes 这样就说得通了，给卤素灯泡用的反射碗切线本身就比较弱，换了通用的 LED 灯头以后性能还会变差，怪不得会有这么大的眩光。

按理说这种车无法通过年检的灯光检测项目。

私自改氙气灯，只要配光做得好也没问题（眩光反而会比做得不好的反光碗卤素灯低得多）。

在照明良好的城市道路里，楼主要对它射远光也其实没啥问题，但会有 1：激化矛盾的风险，2：如果是在照明不好的小路乃至国道的时候，正好有个人夹在俩车之间，这个人就真的 doomed 了。

@tamlok
@dxgfalcongbit
据我所知，未经更改过，没有出故障的奥迪车灯的近光灯有很好的切线。配光的倾斜角度也没有超过国家的-1.0%的规定。而且奥迪车灯的配光一般都做得很好，光束很宽，均匀性也很好。因此即便是为近光灯准备了高达 35W 功率 LED 的 A6L （上一代）的炫光也非常小。

一般来说，使用 LED 光源时，一侧灯头为近光准备的功率多在 20W 上下。

而奥迪车的远光灯功率也不大，国内销售车型基本上都是 17-20W 左右的 LED，如果是矩阵灯的话会因为光束变宽而高不少。

比如 A8 的矩阵灯加上激光辅助远光以后为 64 瓦（如果是 LED 辅助远光则是 58W ），A4 的矩阵灯为 30 瓦。

@daozhihun 看原话的“提供 app 内更新功能”，以为是热修复，但开发者实际的意思应该是“ app 内检测更新”。

@cty0111 这是因为 v2 的 cdn 移到海外了

如果是 needle，tinker 之类的热修复方案的，我只能被迫把它们的 service 给禁用了。

请开发者避免使用应用内更新的特性，至少在 play 渠道禁用此类功能。

这是 chrome76 开启的特性。

这个特性在半年前就准备开启过，但被大量的反对逼回去了。

但是 Google 目前准备强推这个。

@laozhoubuluo 只依靠 Google play 限制 ta 确实很不足，如果是在 iOS 上确实足够。

@azh7138m 有一小部分的 appops 以 special access 权限，开发者选项的方式暴露。

就 scoped storage 来说，Google 目前不允许通过 appops override 应用自己的设定。你会看到用 appops 读取的时候有两个 legacy_storage，而 appops 只能改掉其中一个，另一个因为 manifest 而出现的无法更改。

真是麻烦

@laozhoubuluo

就 IMEI 来说，从 Android Q 开始谁都拿不到 IMEI 了（排除系统 priv 目录，以及少数个例，如拥有 sim 卡密钥签名的运营商软件，profile manager 应用），拿到电话权限也看不到 IMEI。

至于一般意义上的返回随机数，dianne hackborn （这人是 Android 组的老员工，Android 的权限机制是她管的，最近在 reddit 的一次 ask me about everything 活动）的意思是，开发者最终总是能察觉到返回了的是随机内容 /空内容，所以它们不愿意做这件事。

类似的，他们不愿意把 appops 暴露出来给一般用户使用也因为 appops 晦涩难懂。

目前的 workaround 基本上可以覆盖绝大多数的场景了，appops 对付强要权限的，magisk+storage redirect 对付强要 storage 权限的。这样的话除了美团这种以外都能治。

安全和匿名不一定是一件事

没问题。
如果是闪存的话泄漏速度会快一些