multicast DNS，看名字就知道用了 multicast，你上哪整 TCP 去？总不能套个 VPN 吧。

发酵在我国不是也读“发笑”吗？

@wangkai0351 如果用户没有 root of trust，那么这些所谓的 security,trusting 就不是 protect user，而是 protect against user，传递到操作系统，用户连个私有 CA 证书都没权利添加。
用户买了设备却没有私钥，就像买了房子没有钥匙一样，开门都要管家帮你开。希望以后西方 zf 可以推动立法禁止这种行为。

MAC 地址是二层的，你得把运营商对端设备的 MAC 地址加白名单才能访问 😅

最好不要转编码，尤其是有损的格式就不要动了。
封装格式的话，建议 mkv/mka，功能丰富，各种工具支持也好。

阿里对象存储，拿来自建网盘最好不过。

其实我不反对 secure boot 这种一环接一环的签名验证机制，但关键是必须要允许用户自行添加与厂商预置密钥地位等同的 root of trust，也就是说这个 trust 要包含 trust 用户才行。像 Android 某些设备可以自己倒入密钥，自己签名 ROM 然后上锁 bootloader，但还是会被区别对待当作不安全。证书也是一样，用户添加的证书默认不被应用信任，和系统内置的证书区别对待，导致内网部署 HTTPS 服务无比困难，不得不用真正的域名找公共 CA 签证书并且将安全性寄托在公共 CA 上。

他说的没错，arm 上的 TEE 也是一样，所谓的 trust 不是对用户，是对厂家而言的，厂家可以确保用户没有篡改环境。相应的到应用开发者（通过 safetynet ）、drm 等，都是防范用户的“安全”。
凡是预置厂家密钥，并且不允许用户添加与厂家密钥等同地位的 root of trust 的所谓“安全、可信平台”，确实都该炮轰。

lambda 直接 inline，return 能直接结束外层函数这种特性多好。可惜很多语言没有，为了返回错误之类的，只能把 map 改成循环。

彻底禁用 webrtc，或者换 brave 可以精确控制使用哪些接口的 IP 地址。

看起来是个与是否自动保存密码有关的 bug，解释一下就好了。就冲这个回应，绝不会用你们的产品 +1

可以看看 volta，像 rustup 一样管理 node 环境。

其实甚至都不需要你配置域名，只要 cname 指向过去就能直接用 https 访问。当然这个特性容易被滥用，对外服务一般都不开。
caddyserver.com/docs/automatic-https#on-demand-tls

utools 很不错，但也有些臃肿，有个无在线服务的 floss 的替代品挺好的。
另外建议改个好点的名字，可以参考一下同类软件 wiki.archlinux.org/title/List_of_applications/Other#Application_launchers

vscode+clangd+lldb
简单轻量，兼容各种 build system 。

@wizzer rclone 挂载一下，或者某些网盘程序 /文件管理器直接浏览。NAS 内网还行，外部访问就拉跨了，家宽上行不行。

不如加密上对象存储，速度、可靠性远高于自建。 按量付费，个人使用一般用量都不大。