@GreatFinger 我去看了看，releases 里的 assets 有 Source code(zip) ，打开以后只有 git 上的 ReadMe.md

@iold 这个用起来怎么样？我看是.Net 写的，会不会轻很多？

前两天公司要买个路由器就买了个二手 RT-AC68U ，就 200 块。
感觉很值，虽然出了这么多年了，还挺好用。（个人偏爱有线，对 wifi 好坏没啥感觉）

网速可能没问题，但解码能力就比较难说

同步的话，vscode 的同步功能做得相当不错
JB 家也有同步功能，相对感觉差一点
不过都是应用单独的

HTPC ？我以前也想过，然后放弃了入了 nvidia shield 。一方面来说没有为电视场景优化，就是纯纯的电脑操作。
但主要还是贵，而且配置我也挑不好。

@cjpjxjx 你是懂丁达尔的

tiktok-downloader ，平平无奇

用爱发电的可以随意鸽

猛踩一下，在油门达到阈值前的一小段，整个车子是加速的吧
急刹，脑子不太清楚的情况下。我觉得司机很有可能会下意识地把脚缩回来，这样反而更惨了

在等 990pro

1080p 、MetalFX 上采样性能模式、材质质量中等、阴影质量低还有一堆 off 的特效，视频中间部分还常掉到 50 帧以下。。。

还是不容乐观。2022 了，ipv6 还像个新东西，发展实在是太缓慢了。
1 、对于看看视频、上上网这种最大众的需求，现在的 nat 方式仍能满足。
2 、有很多公共场所的网络支持还没有 ipv6 ，估计网管配了 ipv4 后就不管了
3 、计网、师傅教的还是教 ipv4 。练习和使用都是 v4 ，ipv6 其实不同之处还是有，有学习成本
4 、v6 的 ip 实在是太长了，手输实在是太麻烦了
5 、软件支持。有些软件支持 v6 却不愿意默认启用。另外 v6 攻防实践少，防火墙策略比较简陋。

个人觉得 ipv6 发展慢的最重要原因是 ipv4 对很多人来说还够用。没有国家、大型企业确实很难推得动。而且在特别特别长的时间里，ipv4 都不会被替代，只能双栈，慢慢提高 v6 的比重。

不过我还是积极拥抱 ipv6 ，坚决反对直接关闭、因噎废食的做法。因为 nat 对 p2p 联机游戏真的是有很大影响。

对数字 6 我的感觉是很奇怪的，标准是用右手食指按，但其实我觉得用左手食指按更舒服。（另外微软的人体工学键盘好像就是这样的）

我是群辉，开启了管理控制台和 webdav 公网访问，DDNS 。不过更换了端口+使用高强度密码。

感觉 mac 上 webdav 不怎么样，所以现在更多是 wireguard 后用 smb 连接访问。（不过不能用 mDNS 了，只能直接用 ip ）

学 Java 啊，生态最好，工具最全，岗位最多。

个人觉得：没有。
虽然 ipv6 很好，但最主要还是解决当初 ipv4 地址不够用的问题吧。
对于我父母这种看个视频上上网的普通人来说，应该没有什么区别。

但对于 p2p 游戏联机之类的可能还是有帮助的。

由俭入奢易，由奢入简难。尝试了新功能和新语法糖后，做项目的时候仍然要用老 JDK 。还不如先别试新的。

如果我是一个项目负责人：我会推荐用 Java11 ，不是 8 ，但也不是 17 。
首先出于稳定性考虑，只考虑 LTS 版，8 太旧、17 太新，11 正好。
另一方面是兼容性，虽然我觉得 Java 的向后兼容做得非常好，但偶尔还是会有问题，比如之前发现 11->13 时，nashron 就没了。
最重要的是从众，反正肯定有人会去尝鲜，等别人把坑都踩了，自己再上去不香么。

我干过这事，不过具体场景有差别。
是因为数据库里面这个实体的存储形式就是 JSON 。至于数据库字段为啥要用 JSON ，因为这个字段里的内容太复杂多变了。同样的，如果建立实体类，实体类本身也会常变。因此后端就不转化直接传给前端了，反正前端是动态语言，内置 JSON.parse 方便。
尤其是一些显示效果、和后端运行无关的。后端做个大概得验证就好了。