这两个工具定位就不一样。
如果需要准实时同步，只能用 Syncthing ，否则 rsync 简单可靠。

这个问题不是应该找电影院问么？
不过现在的电影票多半是热敏的，挺难收藏的，过几年上面的字就没了。

老以前（ 20 世纪 90 年代末）电话拨号上网时代确实可以一个上网账号在不同地方拨号上网，网费从账号上扣，电话费在哪里拨就哪里扣。
后来换成 ADSL 以及再后来换成光纤以后，貌似“账号”这个东西就没什么实际用途了，都是跟线路 /设备绑定的。

可以的，买千兆的 PoE 分离器，而且得是带变压到 12V 的。

我是 UPS 给主 PoE 交换机供电，交换机 PoE 到光猫和次交换机等给它们供电，AP 也是 PoE 供电，所以即使停电，家里的网络也不会断。这个方案我用了两年了，还是挺稳定的。不过现在遇到个新问题是升级到 2.5G 网络，貌似买不到 2.5G 的 PoE 分离器。

排版乱七八糟，字母大小写不对，不过这两点我一般能忍，因为我不能因为自己对排版有一些要求，就非去要求别人也要做出整洁、好看的排版来，以体现所谓“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 都不觉得有过于清晰。有损压缩压完了就再也回不去原来了，没有后悔药。现在存储这么便宜，未来也会越来越便宜，实在不值得去这么做。