@ysc3839 固件闭源私有编译，已经无解了🥲

@sy1989 这个定制的 openwrt 编译的时候把通用库 glibc 去掉了，导致通过正常 opkg 渠道安装的 executable 全都无法运行，所以应该没办法靠安装一个 luci 解决问题

only conda

@totoro625
叫“云骏数据”

但是上线之后发现一个很致命的问题，我的网络里面提供服务最关键的 NAS 连接不上这个 DERP ，但是其它的设备可以连。导致他们在一个 NAS 没法达到的中转网络里，然后全都连接不到 NAS 。可能 NAT 鸡上层的转换把 DERP 搞得不可用了，现在只能紧急下线，只保留 EC2

```
root@UGREEN-CD13:~# tailscale status
fd7a:115c:a1e0::21 ph default iOS active; relay "ZJ"; offline, tx 1267665596 rx 22989168
fd7a:115c:a1e0::13 hsq default windows active; relay "ZJ"; offline, tx 14420 rx 9508
fd7a:115c:a1e0::1 2chowdpa02k default windows active; offers exit node; direct 192.168.1.10:41641, tx 181812 rx 52248

# Health check:
# - not connected to home DERP region 902
```

@totoro625 去找了下国内的 NAT 小鸡，买了一台镇江电信 50Mbps 的机器测试一下，12rmb 一个月，现在网络里有 2 个 Derp 了，一个海内一个海外

@Joomaen
对先进 codec 有解码需求的唯一选择只有 edge ，我确实是没想到 2023 年 chrome 解 HEVC 都不太利索（更别说什么 10bit HDR AV1 之类）
而 firefox 更是重量级，它完全不支持 HEVC ，是导致你在 b 站看不了部分视频的罪魁祸首

Chrome 在开启硬解的情况下依旧 不支持 AV1 不支持播放 HEVC 不支持任意形式播放 HDR
Edge 以上全都支持，在开启 HDR 的时候甚至支持 HDR Directplay from Emby/Jellyfin

而所谓吹 Firefox 的，Firefox 的解码能力支持比 chrome 还惨烈，基本上处于不兼容状态

低预算 致钛 PC005
高预算 镁光 7450 Pro M.2 2280 （型号很长，叫 MTFDKBA960TFR-1BC1ZABYY ），1700TBW

http://arthurchiao.art/blog/how-nat-traversal-works-zh/

可以支持 zerossl 吗，有些个人化的项目部署无域名 HTTPS 需要他的证书，90 天续期一次

@Lengxi 没买，要不你给我寄一个来🥲

要是管理员看到麻烦帮忙把这两篇都移到 NAS 区，多谢了

@bugsnail
网上的绝大多数测评（软文）的一个共同特点是他们都没有家人。
非管理员用户加入之后才能发现这套系统的很多坑，而管理员专属的很多功能要真的自己亲身摸过才知道哪里出了问题，不是简单打开看一下跟观众介绍一下我们绿联支持 xxx 功能这种程度能够发现的

@icefrogisgreat 不太需要，你跳转到文章的第(1)部分的目录窥探，对着取数据就行。至于 raid 的话按常理在别的系统要手动挂载一下吧，也不排除够智能的系统会自动识别

@Ericality
所以我没换系统，因为家里人都能用明白，而且他们都没有电脑，用的手机端
我自己想要折腾，才发现这么多毛病，秉承着来都来了的原则，也只能硬着头皮靠自己克服困难了

@TORYOI
docker update --restart=[policy] [container]

policy:
no
on-failure[:max-retries]
always
unless-stopped

例如
docker update --restart=unless-stopped jellyfin

召唤一下之前帖子里蹲更新的朋友
@HongDoNi
@daya

文章太长，有 30 分钟 CD ，晚点洗完澡再继续发

@listenerri
测试了一下，遗憾的是似乎没有效。我去 openwrt 论坛提问，核心开发者是这样子回答的：

问题: Is libc.so universal for x86_64 Openwrt device?
回答: It is not, even less when it comes to vendor provided firmwares (who seems to have chosen a non-default glibc based build, instead of OpenWrt's default of using musl). There isn't even binary package compatibility between different versions of OpenWrt (even less for the libc), when it comes to 3rd party or proprietary builds all bets are off.

@flyqie
好消息。OpenWrt 的系统镜像是 ROM+Overlay 模式的，系统镜像固定烧在 mmcblk0p*的分区里，对系统做的所有改动都在/overlay 层上，不会影响固件区本身，而且这 ugos 开机就把/rom 挂载上了，还省得我搞 emmc dump 。
我直接把整个/rom 分区打包下来，不确保完整性，不一定能用。
https://1drv.ms/u/s!AnUR6E0c9koezg8AJ6hHrTSkZFgq?e=uBODp8