https://cloud.tencent.com/developer/article/1888426 ，善用搜索引擎：nginx resolver upstream
似乎 upstream 和 resolver 没有良好解。

对象存储很重要？跟 seafile 的团队沟通过，他们的底层本身就是某种形式的对象存储。
才 10 个人 15 个人，上个 seafile docker 就轻松解决问题。我这边都支撑了 50 人规模的文件共享，从 seafile1.x 一路用到现在。

com.alphainventor.filemanager

如果想要知道怎么做到实例 parent 嗲用了 Child.print 的话，可以了解一下 JAVA 虚拟机以及 bytecode

如果想要知道为什么要这么做的话，那就得问 Bjarne Stroustrup 和 James Gosling 了。🤣

我好像提过类似的问题。我当时的问题是想办法外部调用的时候，调用 Parent 的而不是 Child 的。
但这确实就是 JAVA 的继承机制，重写 overwrite 父类方法。从 bytecode 看，Child 的实例，也就是 parent 相应的 method 入口在 Child.print 上，除非反射，否则类加载器永远无法找到 Parent.print 。

另外这里还有修饰符，print 的没有显式写，所以默认是 public ，那 Child 就 overwrite 了 print ，如果修饰符为 private ，那就不会 overwrite ，本级调用本级，次级调用次级，不会互相串。

没说明白到底需要几个 2.5G 设备啊

我用了 r68s ，两个 2.5G ，NAS 上有两个 2.5G ，这样台式机 2.5G 、无线路由（ AP 模式） 2.5G ，r68s 的一个 2.5G 串到 NAS 上再串到台式机上，另一个 2.5G 直接接到无线上。

如果不做光猫桥接，好像 NAS 上开旁路由就行了，然后弄个 USB3 的千兆 USB 网卡，设定虚拟交换机绑定三个网口，不提供 DCHP 不提供 NAT ，完活。

@locoz 140#
你看过机动车的使用说明书么？知道为啥读不懂么？就是各种奇葩的人太多了，厂商为了确保自己方方面面都说到，不出现问题，才把简单的问题长篇累牍的说圆喽。
当你收到几个法院的单子，你就会想，特娘的到底是我的错还是用户的错，或者我想办法规避我的错——美国那种海洋法系的，就会遇到这类情况。偶尔再来一个集体诉讼，很有可能直接破产了。

不是说 SB 的毛病要贯着，你如果站在车厂的角度，当然要规避责任啊。

@wangyuyang3 74# 请看我 38#说的，这是一个意识的培养过程，不是换了电车立马就是的，特别是没有开过别的车，上来就是电车就是 T 的这款。正如楼内所述，干脆开一个新的准驾车型，不要跟传统操作模式混淆。

@xuanbg 62# 正常心智的人都没有出事故，Y 也不是个个出事故。油车也不乏把油门当刹车踩到底的。不要用正常心智去推断异常心智，但是机动车这个具有伤害自身和他人能力的工具，要在一定程度上避免异常心智的发生，特别是某种操作方法更可能引起异常心智的时候。

@inoreader 57# 你说的肯定对，我始终坚持的是，不知道油门在哪，也不能不知道刹车在哪，脚的正常位置 /舒服位置是踩刹车，踩油门要稍微拧一下以便应急踩刹车时可以完全用力——但这都是对机车车这个危险物品、对安全意识比较高下的结果，不要视图认定所有机动车驾驶员都有很高的安全意识。

@locoz 48# 对于清楚理解机动车的，都知道怎么回事，我当年手动挡还能降 3 档拖车速不踩刹车过路口弯呢。但是你能保证全中国道路上的驾驶员都有这能力水平素质？听到过一群小--（防止 X 拳）叫着喊着单踏板模式真好，你说我该怎样理解她们说这话的内心？

另外，至于本案，不是说单踏板是罪魁祸首，只是顺着话说到此了。我不反对智能驾驶，但是智能驾驶的前提是非常可靠，别把半成品拿出来公测，机动车是会造成人身伤害、人员伤亡的——手机大不了就是死机，能咋地。智能驾驶也要符合常规驾驶理论和习惯，别整新名词，简单一个强动能回收模式叫“单踏板”（咱不说是不是官方用词吧，至少大家默认了）造成了多少误解，以至于误解到“没有刹车踏板”；还有高级辅助驾驶，老老实实叫辅助驾驶，非往无人驾驶上意会，等驾驶模式无法判断前车导致伤害的时候，知道说驾驶员不能怎么样怎么样。

@xuanbg
当习惯了不踩电门=刹车的时候，可能并不会行程下意识的踩刹车动作（因为平常不踩就是制动）；
当需要人为介入强力制动时，由于没有形成意识，所以不知道踩哪，但是好像还应该踩哪，于是一脚电门踩到底。

建议你这台电脑脱离现有网络环境，换一个网络环境看看什么情况，这第一跳就牺牲，显然是路由表有问题了。route print 看看，或者强加一条路由记录，route add 183.246.191.179 mask 255.255.255.255 192.168.62.1 ，有没有可能突破第一跳。或者看看他隔壁的 IP ，什么 178 、180 之类的。

TRACEROUTE

@elfive 3#
搞过一个游乐场的游戏，过山车很哈皮，不能站着，必须坐下
赛车玩的是 assettocorsa 、raceroom ，还有美卡，配合方向盘，无敌了
飞行有 MSFS ，但是 3090 似乎也扛不住，帧率不高，另外就是操纵杆不像是汽车方向盘可以盲操。

大法：你说能不能？

这难道不是加载了 TTC/TTF 之后，读取相应 key 为那么，显然其 value 么？完成了从 name 到 file 的对应关联。

然后在 css 中使用，你能确定客户机安装了相应字体么？那不是需要 @ media 传送给客户呀，那自然可以解析自己的 TTF/TTC 获取到应该使用的名字了呀

删掉 APP ，然后关掉 AppStore

你这个带 IP 的需求，基本上就，额，需要看协议。
HTTP 可以带 X-FORWARDED-FOR 塞进 HEADER 里告诉服务器客户的 IP ，但是确实无法修改 IP 包里的源 IP 实现服务器的 IP 认证。同样的，如果 RDP 协议只认 TCP 包里的源 IP 。
然后如果 Proxy_Protocol on 的时候，RDP 服务器拒绝了链接，那只能说，RDP 不支持这个插帧。

https://www.jianshu.com/p/cc8d592582c9

孤家寡人，有何不可？

@billzhuang 6#
换了 r68s 以后，NAS 就回归 NAS 本身了，偶尔 qb 一下，N4005 基本够用。其实如果没有 pt ，VM 里边也没问题，跑到 1000Mbps 进行 NAT 的时候稍微吃一些 CPU ，但如果同时上了 qb 就不行了，又要 NAT 烧 CPU 、又要 PT 烧内存和 IO ，这就折腾不过来了。所以这才干脆考虑双线汇聚破千兆以及更直接的 2.5Gbps 内网，实体化到 r68s 上。