感觉交互不如....Windows8

@wfxiong1990 #1 纠正，通话录音是有的，我的是 k40 ，miui13eu 版本是有通话录音的，14 我当前刚刷，还没试过

流程拉太长了

把 ublock origin 关了就不会复现了，可能是为了恶心广告屏蔽插件用户吧

@JamieChen #6 dns 可能会泄露这个

https://log-sdk.ksapisrv.com/rest/wd/common/log/collect/misc2


f12 里面疯狂加载这个东西

互联网就这这几个盒子里面？（曾小贤问的

啥服务商这么干的，给出名字避坑

切 cmd 试试呢

@Chaconne #3 你应该预防，先设置复杂密码，这个邮件没什么可担心的

@selca #1 网页乱的估计是为了不被 Google 的垃圾邮件拦截给干掉，做了特殊处理

就是普通的敲诈骗局，不用理会

@raycool #13
@brsyrockss #18

也就随便问问，这一看就是亏本的活儿

多少钱一个月，如果给得高，我租一间房子给你弄

我的这思路不一样，我搞了俩 client ，通过不同的账户来分流，A 账户直接出去，B 账户走 warp 出去

C:\Users\at>ping 2400:6180:10:200::27:d000

正在 Ping 2400:6180:10:200::27:d000 具有 32 字节的数据:
来自 2400:6180:10:200::27:d000 的回复: 时间=368ms
来自 2400:6180:10:200::27:d000 的回复: 时间=374ms
来自 2400:6180:10:200::27:d000 的回复: 时间=377ms

2400:6180:10:200::27:d000 的 Ping 统计信息:
数据包: 已发送 = 3 ，已接收 = 3 ，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 368ms ，最长 = 377ms ，平均 = 373ms
Control-C
^C
C:\Users\at>ping 2400:6180:100:d0::772:8001

正在 Ping 2400:6180:100:d0::772:8001 具有 32 字节的数据:
来自 2400:6180:100:d0::772:8001 的回复: 时间=308ms
来自 2400:6180:100:d0::772:8001 的回复: 时间=307ms

2400:6180:100:d0::772:8001 的 Ping 统计信息:
数据包: 已发送 = 2 ，已接收 = 2 ，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 307ms ，最长 = 308ms ，平均 = 307ms
Control-C
^C
C:\Users\at>ping 2400:6180:0:d0::c34:5001

正在 Ping 2400:6180:0:d0::c34:5001 具有 32 字节的数据:
请求超时。
请求超时。
来自 2400:6180:0:d0::c34:5001 的回复: 时间=107ms
来自 2400:6180:0:d0::c34:5001 的回复: 时间=106ms

2400:6180:0:d0::c34:5001 的 Ping 统计信息:
数据包: 已发送 = 4 ，已接收 = 2 ，丢失 = 2 (50% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 106ms ，最长 = 107ms ，平均 = 106ms

C:\Users\at>ping 2409:8028:2000::1111

正在 Ping 2409:8028:2000::1111 具有 32 字节的数据:
来自 2409:8028:2000::1111 的回复: 时间=32ms
来自 2409:8028:2000::1111 的回复: 时间=31ms

2409:8028:2000::1111 的 Ping 统计信息:
数据包: 已发送 = 2 ，已接收 = 2 ，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 31ms ，最长 = 32ms ，平均 = 31ms
Control-C

很多都是基于配置式的，人工标记某个文件夹是哪个 app 生成的，然后下发到文件管理器。

还有一部分是基于包名来识别的，一部分文件夹本身就跟包名一样

@EVANGELIONAir #4 老哥锐评一下 vlc 呢，这货能排上号吗

互联网的垃圾和垃圾人太多了，辛苦搜索引擎厂商优化