我觉得相比安全问题，更多的是等看后面的商业化方案出来吧。不要想着别人会做慈善。

阿里云和腾讯云的每一款新功能出来基本上都是公测免费当小白鼠，然后过段时间稳定了就开始收费。

折腾连通盒子还不如玩黑豹 x2 吧，内存太小了以及芯片性能也不够。

CF 在全国各地能否访问和打开时间也是个迷。如果是玩具项目那随意，正式项目还是老老实实按照规则来吧。

5 年前我就用 512G 的闪迪移动固态试过了，使用一年左右的时间完全没问题。

618 淘宝给的钱太多了，大家都恰相当于没恰。

感觉淘宝为了数据好看，什么烂流量都接。反正受害者是那些广告主，淘宝自己躺赚。

就逼乎商业化成那鸟样，后续内容爬不了也无所谓了， 反正之前记录还在。

自己的应用难道不应该直接写一个 js bridge ，通过网页调用 iOS native 的能力来获取到设备推送 token 吗？

为什么不试试 tailscale+自建 derp 国内节点呢？

vpn 流量最好不要去过墙，跨境这块只要是不认识的流量会进行不同程度的干扰导致无法正常使用，不然现在大家也不会想方设法去做混淆了。

目测就是和 tailscale 一样，先中转再尝试打通之连。如果打通之后 P2P 就能省去绿联自己的中转服务器流量，速度大部份时候会变快，也有可能因为跨运营商变慢。

我不太看好 Windows on Arm 。兼容性太好会导致看起来还行，用起来又会总觉得差那么一点。 比如 x86 虽然靠转译虽然基本上也能用，但是明明有 arm 版本可以更流畅省电。开发商会评估兼容迁移的成本，很多历史包袱又会让开发商觉得又不是不能用，这一点点用户量不值得去迁移。 两头讨好的结果往往就是会像上一代 windows + 高通一样的下场。

生态是一个巨大的包袱。 这点还是很佩服巨硬的，强大的兼容性之下是有巨硬在负重前行；反观果子就是轻装上阵，每次稍微恶心一下用户和开发者。

SCRAM 适合后端服务、App 之间进行通信沟通，但不适合 web 前端这种使用下发脚本来执行的环境。

假如 cf 和 aws 这类 cdn 大厂需要做恶，它可以选择注入脚本监听用户输入框。整个运行环境都不可信任了，谈加密有意义吗？

@Sivan 别乱讲，当时 HFS 升级 APFS 的时代我也经历过，系统升级的时候自动转换消费者根本不用操心。 反倒是有网上还有人找到方法让升级系统的时候关闭自动转换 HFS 。

试试 terraform 。纯配置化管理，改完配置 terraform apply 就可以生效。


https://registry.terraform.io/providers/tencentcloudstack/tencentcloud/latest/docs
https://registry.terraform.io/providers/aliyun/alicloud/latest/docs

我都是 1password7 用户转成订阅制的。

现在 1password8 订阅制的浏览器插件版本还在不断更新，能保证大部份网站都能正常填充。并且要了 macOS 的辅助功能权限，保证不装插件也能获取到当前的浏览器是哪个网站进行填充，以及 app store 这类原生应用也能快捷键一键填充。 我记得早期原生应用都是得手动复制或者拖拽密码过去的。

@leonme 4T 以上的版本大概率是氦气盘，这类企业级用的东西，往往都是不在乎噪音和发热，反正有独立隔间并且有空调吹着。

allow ips 是给连接客户端向用的吧，比如我的 mac 连接了远程的 linux ，我希望访问到 linux 所在的局域网，那么 mac 上的 wireguard 配置 allow ips 就写 linux 所在局域网。

服务端向只能选择开启或者禁止全部转发，客户端向连接进来随便访问该服务端的内网或者外网。 但是内网也不是随便访问的，得在服务端内网配置 wireguard 的网段流量回到服务端所在内网 ip 。不然 wireguard 内网段在局域网里面是只有去程没有回程的。


最后，为什么不试试 tailscale 呢？ 在不自建的前提下轻轻松松完成“仅能够访问内网的某些网段”。后面可以配置 acl 规则进一步限制哪个客户端访问哪个网段、ip 、端口都能满足。