想稳定的话还是推荐自建

抽几个 Copilot X ？

个人认为适合这种超冷备的场景：原始存储大概率不会坏，就算坏大概率也只影响个别文件，加个备份满足 3-2-1 法则。

不收流量费的几家对象存储试过了么？

@fengyaochen 如果申过单域名 SSL 证书就很容易发现

gpt-3.5-turbo-0301 的最大 token 数是 4096

浏览器基本都可以导入，但 Edge 应该是最容易误点的（非首次启动有时也会有请求导入的弹窗）

就算应用不用，大内存对写入速度也是有帮助的
https://global.download.synology.com/download/Document/Software/WhitePaper/Firmware/DSM/All/enu/Increasing_System_Performance_of_Synology_NAS_Solution_Guide_enu.pdf

@neroxps IPv6 的超大地址空间防的是外部暴力扫描，相比 IPv4 攻击面确实大幅减少。但这一特性确实无法解决主动暴露回访和内网内鬼泄露。

外网回访的情况很早就出现了。一年多前我有发现 b 站直播用的 xx 云 CDN 会回扫 IPv6 端口，直接触发了卡巴斯基的警报。
至于内网内鬼那威胁的上限就更高了。设想一下，如果在 App 中结合 frp 类的功能，那所有假设内网安全的端口都可能被看光光，都没网关什么事了。（好在暂时还没发现这么缺德的）

BT 作为一个主动汇报 IP 地址的机制，碰上弱口令端口是一个实实在在的风险。由于 v6 路由器防火墙配置门槛比较高，设备本身的安全建设就很重要了。建设完成后最好进行测试，以免碰到 Docker 绕过防火墙这种坑（ /t/915279 ）。另外也可以利用 IPv6 地址空间大的特性给风险应用分配独立的 IPv6 地址（ /t/902568 ）。

个人认为，适应 IPv6 的做法是放通网关防火墙，强化设备安全（零信任持续验证），两者要提要一起提、不可偏废。

@cnbatch

链路本地地址：169.254.0.0/16 对应 fe80::/10
私有地址：10.0.0.0/8 + 172.16.0.0/12 + 192.168.0.0/16 对应 fd00::/8

@Xymmh
不推荐把 v6 的公网类比成 v4 的私有地址，虽然是为了便于理解，但可能会引发新的混淆

没必要太在意家宽的 80/443 ，即使侥幸没被封也不知道能用多久，不如一开始就假设没有。

“看光猫 IP 和网站显示 IP 不一致是 NAT”是 IPv4 下的经验。过去运营商用的是 NAT ，内网与外网是无法保持一致的，所以可以借此判断。目前，NAT4444 之类的操作已经打破了这种判断方法。

IPv6 与 IPv4 不同，如果正确配置，每一台设备都应该有一个或更多的公网 IPv6 。当前没听说过国内运营商会给家宽做 NAT （反而浪费资源），只要本机获取到 2xxx 开头地址即是公网。当然，是公网不代表可以接收入站请求。这可以在本机开一个非常规端口的 web 服务，放通本机、路由器、光猫的 IPv6 防火墙，通过外网访问来测试。

v6 用途参见 /t/887939

很不错，期待把 UI 再完善一下，处理好 API 没响应或者文字数过多时的问题

MLC 的供需关系应该没太大变化吧

工作需要的是能力，不是学位。学位只是鉴别能力成本比较低（相应的会有些许反例）的同行方式。有其他方式能切实证明能力出众，至少在市场经济下是不会被埋没的。