可以试试 avahi reflector mode

我之前尝试过成功用 avahi reflector 把 wireguard 和家里局域网的 mdns 打通，AirPlay / Apple TV Remote / HomeKit 直连 / macOS file sharing 都可以顺利工作。

不看好

vscode 目前又没有明显的性能瓶颈。即使有，问题也出在插件。
你 zed 一样是 LSP ，那插件一样会有瓶颈。

@Twins666 平时我在家都是路由器翻，在外常开 surge 。速度方面的差别基本无感知。
和老婆共享图库，她出门在外是直连，不翻。直连的照片同步速度比以前稍慢一点，但最终都会同步，无非是多等一会。

@Twins666 我之前遇到的现象是，我肯定自己网络和苹果国内外服务器通信都正常（抓包确认有流量），但是 HSV 就是不能录制不能回放。所以肯定是苹果自己内部出 bug 了，毕竟国区是二等公民，HSV 还是小众功能，美国一众苹果工程师不会专门来测试国区网络。

转美区后我再也没遇到上述问题。

---

以前账号在国区还经常遇到网页版 icloud.com.cn 不定期登录后报错，某些时候完全不可用。转美区再也没有这些心烦事。
不过真正让自己决定主账号转区是因为 app 备案制。

即使账号是国区，HomeKit Secure Video 上传视频和回放视频走的都是苹果自己的 17.x.x.x 段服务器，并没有在国内云上贵州。所以体验很差。有时候即使家里路由器翻墙，抓包看到到苹果服务器网络也正常，有流量，但就是不能录制、不能回放。

后来我把账号整个转到美区，就再也没有遇到这个问题了。

可能和汉语的语言特点相关。欧美人听歌对歌词依赖就不是很强，就像他们看电影不需要字幕一样。

> 拿到杜比视界授权后，杜比实验室会给一套解码 DV 的算法吗？

早期的电视、播放器，必须用杜比的专用芯片，杜比才给认证。那么猜测这个芯片应该是包含了 HEVC 解码器、色彩空间转换、tone mapping 、EL 层解码 等所有功能。

后来杜比认证不再要求专用芯片，可以由电视、播放器制造商自己软件实现。那么猜测杜比应该会提供相关算法实现或者闭源动态库。我觉得给动态库的可能性比较大。Windows 从商店安装了 Dolby Vision Extension 之后，就会获得几个有杜比实验室签名的 DLL 。

HDMI 2.1b 已经把 dynamic metadata 标准化，以后也不再是 DV/HDR10+ 专属了。

杜比视界本来就有一定 backward compatibility
https://en.wikipedia.org/wiki/Dolby_Vision#Profiles

现在最常见的是 profile 5 （流媒体）、profile 7 （蓝光原盘）、profile 8 （流媒体和手机相机拍的视频）
而他们的基础编码都是 HEVC ，用系统 HEVC 硬解即可。对于 profile 7/8 ，直接 HEVC 硬解并且按照 HDR 显示输出，就相当于 HDR10 。对于 profile 5 ，额外多一步色彩空间转换，也相当于 HDR10 。
做到这个程度，观感上已经可以感知到正确的色彩和 HDR ，播放器就已经可以宣传”支持杜比视界“了。

但是真正完整的杜比视界，还包括 dynamic metadata （ RPU 层），以及双层杜比（ profile 7 FEL ）。前者需要显示设备支持（除非 side-by-side 对比，否则肉眼很难感知区别），后者几乎没有播放器实现（大家显示器最高就是 10bit 色深，按照 FEL 解码出的 12bit 片源基本看不出区别，除非刻意在 EL 层塞入特殊效果的数据）。

Ansible

难怪之前发现我的光猫超密莫名其妙变了，原来超过时限会下发新的密码。
还好我的光猫能破解出超密。。

@orangie 我也一样。直到和美国人工作才发现他们读库伯奶提斯，感到很奇怪

@skyworker 你遇到的是 Let's Encrypt OCSP 地址被墙，但这不是因为“免费”造成的。

1. 相当于保险。出现 SSL 相关漏洞造成损失，CA 有责任赔付
2. OV/EV 有信任加成
3. 有效期更长，减少运维成本（以前还可以长达三年五年，现在最多只能 1 年了）
4. （从采购视角）证书利润较高，相应的返点也比较高，花公司的钱鼓自己的腰包，何乐而不为
5. 有些特殊用途的证书目前只能花钱买，比如代码签名

我的认知是, c 语言很简单, 甚至是难度相当低, 原因为以下几点

c 语言几乎很少迭代, 语法很少变化, 你不学习, 也可能看懂 20 年后的代码
一些所谓复杂的语法, 后面其实包含非常简单的原理, 比如各种复杂声明语法, 背后无非都是指针那一套。不过有时候虽然了解原理你也根本写不出来那些 ugly 但又非常高效的代码。
c 库一点都不庞大, 标准库就那点函数，这年头也没多少新的第三方库，绝大多数人可以说 90%模块都用过
c 使用范围很窄, 基本上只用在那些历史悠久的基础软件上

https://i.imgur.com/agAJ0Rd.png

unix 时间戳是最不容易出错的，不用考虑夏令时，不用考虑闰秒，不用考虑特殊时间点（比如这个 https://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-epoch-milli-times-in-year-1927-giving-a-strange-r ）

几十年来，web 一直都不是最优秀的 GUI 技术，但却是生命力最强的。

如果设定了 500M 上行，brutal 算法就会按照最低 500M 速度发包。brutal 算法检测到丢包时，会最高补偿到 1.25 倍的发包速率。因为 500M 上行远超你的上行带宽，所以严重丢包，于是 brutal 又补偿到按照 600M 速度发包。
大量丢包造成的重传可能又让上行流量放大数倍。

我觉得从运营商看，这个流量特征更像是 DDOS 而不是 PCDN 。不过我从来没听说过运营商会因为 DDOS 而局停。