排版乱七八糟，字母大小写不对，不过这两点我一般能忍，因为我不能因为自己对排版有一些要求，就非去要求别人也要做出整洁、好看的排版来，以体现所谓“Professional”。

重点是没有什么亮点，那个 PR 的含金量一般，但被重点拿出来说，反而让人误判断“是不是最高也就这点水平了”。不过有参与开源项目的经历（哪怕就是提交一个 Trival 的改动或者 Issue ），在我这里是加分项。

看应聘什么职位，如果是应届生或者外包，基本上我还是会给面试的，能不能过就看聊得如何了。

@rshun
多谢指点，虽然还是没有完全搞明白，不过我照猫画虎把我要的功能搞定了。

方法是在 /usr/share/nftables.d/ruleset-post 下加一个.nft 文件，内容如下：
table inet sometable {
set test {
type ipv4_addr
size 65536
}

chain prerouting {
type nat hook prerouting priority 0; policy accept;
ip daddr @test meta l4proto {tcp,udp} redirect to :1080
}
}

然后重启 firewall 就可以了。

不能直接写在 /etc/nftables.d 中是因为那下面的文件会被 include 在 fw4 这个 table 里。即使我去掉外层的 table 也不行，原因我还没搞清楚。

dnsmasq 的配置类似于这样（ dnsmasq 版本必须手工更新到 2.87 或以上）：

server=/somedomain.com/127.0.0.1#5300
nftset=/somedomain.com/4#inet#sometable#test

这么写只支持 IPv4 ，如果要支持 IPv6 方法类似。

@rshun 继续求教。

试了一下，一模一样照抄还是不行，还是报一样的错。在 OpenWrt 22.02.2 上和 Debian 11 上都是这样，nftables 的版本是 0.9.8 ，内核是 5.10 。
```
/tmp/1.nft:8:34-37: Error: transport protocol mapping is only valid after transport protocol match
ip daddr $test_list redirect to :1080
~~~~~~~~ ^^^^
```

试了一下，一模一样照抄还是不行，还是报一样的错。在 OpenWrt 22.02.2 上和 Debian 11 上都是这样，nftables 的版本是 0.9.8 ，内核是 5.10 。
```
/tmp/1.nft:8:34-37: Error: transport protocol mapping is only valid after transport protocol match
ip daddr $test_list redirect to :1080
~~~~~~~~ ^^^^
```

@rshun 这个没有用到 set ，不过就算是写死 IP 好像也不行，我是这么尝试的：
```
root@OpenWrt:~# nft ip daddr 111.111.111.111 redirect to :1080
Error: transport protocol mapping is only valid after transport protocol match
ip daddr 104.244.42.65 redirect to :1080
~~~~~~~~ ^^^^
```
貌似匹配 IP 不能重定向去端口。

@MYDB 杭州电信多拨你能叠加出稳定的 200Mbps 上传？我不管怎么叠加都只有总计不到 90M ，而且丢包严重。改成 100M 上传后，单线 110M 左右比较稳。

我 14 岁应该学会了 DOS/WPS/FoxBASE ，还有 BASIC/LOGO/C ，正在学 Pascal 。那时候 PC 的主频普遍还没有上 100MHz 。

买早了几天，没享受到 100 优惠。

优点不说了，就等待风扇的改进，默认风扇全速转动（貌似不能调速）从出风口散热片缝隙发出高频嘶嘶声，我把它放在我的 DS918+和 HPE Gen10 Plus 边上，两台机器的风扇加 6 块硬盘的噪音都盖不过这个小东西的风扇的声音。而且即使在这样的全速风扇压制下，大冬天的轻载 CPU 温度仍然有 65 度。

@1423 这个我确实没有试过，因为我没有条件试。只能从理论上去推导一下。
如果这个效果可以重现的话，可能可以抓一下包，比较一下两种情况下请求的差异，这样可能可以分析出来根本原因。

@1423 CNAME 没用吧，CNAME 还是依赖客户端解析。得自己搞个域名直接做 DDNS 才行。

11 楼的办法比较保险。如果确实不担心 SSD 坏的话，13 楼的办法把 HDD 从 RAID 里踢出去也是可行的。

mt photos 可以，可以自建，但是不开源。

经历过 Photo Station 时代就很容易理解这里面的原理，共享空间就是为了一定程度上兼容以前的 Photo Station 的。
Photo Station 一直就是独立端口的服务，并且权限体系脱离群晖正常的文件权限的体系的，现在 Photos 的共享空间就是继承了这些特性。

所以我从来不用 Drive 里的 Office 套件。

类似把原来高清的图片缩分辩率、把视频转码压缩体积、把音乐从无损变成有损这样的事情，十几年前我经常做，现在我已经不做了。十几年前 320×480 分辨率的视频都能看，现在 4K 都不觉得有过于清晰。有损压缩压完了就再也回不去原来了，没有后悔药。现在存储这么便宜，未来也会越来越便宜，实在不值得去这么做。

看一下《迷雾》 The Mist ？

@piku 走“正规”渠道（比如 File Station ，Samba 等）放进去的文件都会生成缩略图，不管是不是在 Photos 下。但是自己用 scp/命令行 cp 等方式放进去的文件，不会生成缩略图。

@Apol1oBelvedere

https://i.imgur.com/KV69oUc.png

说的就是双击打开看到的图片。以图中那个 6.6M 的 IMG_20221203_150150.jpg 为例：默认情况下，会下载缩略图（右边看到的 1.3M 那个请求），如果点了那个 1:1 的图标，会重新下载原图（右边看到的 6.9M 的那个请求）。

常放进群晖的图片，都会生成缩略图，放在同目录下的 @eaDir 中。File Station 中点击图片打开，看到的也是缩略图，一般是几十到 几百 K 的大小，除非你去点 1：1 那个图标，才会切换成原图模式。所以我其实有点不理解楼主倒底遇到了什么问题。