@Leonard 我家移动百兆家宽，美国内陆套 cf，从某黑黄站拖视频能把下行跑满，你馋不馋

@YooJoo #11 到附近营业厅分店上门问问，很多地区营销活动不会上官网和掌厅

@my2492 #4
github 上有个“年久失修”的项目，叫 cow，cow proxy，一个套娃代理，自动检测目标能否直连，自动选择是否代理、走哪个代理。
这个程序当年也是相当流行，现在用的可能不多了。但我一直在用，虽然不能上移动端，但是在 PC 上体验相当好。

首先遇到这类场景我反正无论如何不管怎样都开头无脑推荐 zerotier 先走一波。
反正值得一试，不行再说。

接下来具题具析：你用的思路，其实就是 Port knocking （端口敲门），只不过你这儿是 IP 敲门。
好了，结题，建议你上 github 细细搜一下，现成的实现应该不少，就算不能直接拿来用，也能直接拿来改。

大不了再开个移动宽带，白菜价

就算不限制也不要把 CIFS(SMB)、NFS 之类的服务端口暴露到公网，这类协议虽然看似都有不弱的加密、鉴权机制，但那是针对内网环境（内网的风控难度相对外网是很低的）。

如果实在要从外网访问，至少要包在加密通道里，比方说用 SSH 端口转发，这样就好多了。

@laike9m #13
关于这个真不是问题，如果 xyz 被占用了，完全可以搞一个 alicebob.xyz 的，pypi 上有些人就喜欢用这种方式命名自己的包，哪怕那个名称并没有被占用。

其实你一上来就相当准确地概括了当前阶段类型提示的意义和价值：提示（废话，拖走……
提示开发者，提示用户，提示 IDE 软件，比如 pycharm 和 pycharm 用户们就确确实实能从 typing 获益匪浅。
至于性能，提示只是提示，动态类型还是动态类型，运行时类型检测该绕不开还是绕不开，肥胖且非线性的数据结构导致的 CPU 缓存命中该 miss 还是 miss 。
cpython 的性能就这么回事了，高 IO 应用基本不拖后腿，高 CPU 应用肯定拖后腿，如果这后腿拖不起的话就老老实实写 C 扩展。说白了要性能就得放弃动态类型嘛，反正有 cython，改静态类型也不难。
说回 typing，typing 就是通过提示来强化开发和使用的体验的。
至于 typing 的学习成本，反正我都是现用现查现学现封装现扔的，我觉得大家也可以这么弄。

@ysc3839 #11
你的意思是，如果那边合并慢了，你会帮我催他？
或者 OpenWrt 的维护者会秉持着与你一致的信念与理想和你一起帮我催他？
或者因为你用“首先……不代表……”造了一个句，所以世界线因此而收束，因果律因此而变动，神秘的东方力量扭转了 github 服务器的内存比特，从而使我提交的 PR 被自动合并？
再简单直观，那也不是从我的需求角度出发所看到的景象。
简单直观不能修复 bug，简单直观不能增加功能，简单直观不能让我马上就有工具用。
再说你所谓的简单直观其实从一开始就是站在你自己的角度讲的吧？充其量会稍~~~微~~~考虑一下那个项目的作者？
没有考虑我的难处吧？
没有考虑我的感受吧？
没有在乎我的心情吧？
没有在乎我的需要吧？
呐，你自己说，像你这样自私傲慢的评论，我该怎么回复才好呢？

@ysc3839 #9 那边几百个 PR 等着等着合并，我排到猴年马月？

@SingeeKing #3
因为 fork 副本并不好用：
1. 无法从公共源获取更新
2. 大大增加了自维护的代码量（虽然副本中的绝大部分代码没变，但是总量很大）
3. 与原版和谐共存的成本飙升

@shijingshijing #69
啊，我又来了，我还要补充几句，主要怪我眼神不好，没看到你把我关于软件文档的描述硬是要往 SDK 上做类比。

我啥时候提到过 SDK 了？嗯？
我甚至故意举了一个与软件开发无关的例子，我关于软件文档的例子用的是 ffmpeg，我指的官方文档是 ffmpeg 的命令行参数文档，这是个彻头彻尾的用户使用手册，哪来的 SDK ？
然而就是这么一份 FFMPEG 用户使用手册就已经算得上是“鸿篇巨制”了（对用户而言），且不说篇幅巨大，大到想用关键字搜都不能一下子定位到条目，更不用提这个软件很多特性很多规律甚至尚未被文档化，其中一小部分甚至连开发者自己都用不利索。用户社区内，大家既依赖这份官方文档，也同样依赖互联网上的笔记、问答来分享经验。“精通是不可能精通的，只有一边查文档一边开搜索引擎，日子才能过的下去这样子。”
至于 SDK 文档，你当世界上的 SDK 文档的体量和复杂度和细致度都一样哦？
写的细的软件文档在已经熟络整体的情况下是好事，因为知道怎么查，而且查的快，而且查到的很详细很准确，但是对刚上手的开发人员这就是噩梦；写的简略的文档则情况相反，刚上手时这是一份很好的指导手册，然而很多细节上面没有，得自己尝试或者询问他人。所以成熟的文档是既有巨量篇幅的细节与索引，又有一份面向新手的简介，实现过渡。然而这样的文档一般是成熟的框架、产品、平台的文档，这年头经常开发到一小半就拿出来用 /卖的东西太多了，文档只能逐步完善，这过程中还会有大改，等最后最终定型了，估计这套东西也快过时了。
但即使如此，无论是已经定型的，还是尚在发展的软件，不管是最终产品，还是用于开发的环境、框架、协议、平台，它们的文档论篇幅论复杂度都不会比硬件的文档简单。

你连手册里芯片有个变体这事都能拿上来专门讲一讲，干嘛，欺负这里硬件工程师少？
变体那么多，那是市场需求，客户需要，全写在手册上是尽本分，是为了用户能第一时间确定自己需要的元器件是什么型号、什么封装、什么包装，有些已经停产或者即将停产的用户还得考虑着手做新的替代设计。
有的产品变体能有十几二三十种，甚至更多，这么多变体难道都是给你一页一页慢慢翻看细细品味的？你要是已经定型了就赶紧找到对应的型号，该画封装画封装该画板子画板子。你要是还没选好型号赶紧和其他设计组多沟通赶紧把型号定下来，需要样品该申请就申请该买就赶紧买。
元器件数据手册里面的每项内容，就是这个元器件系列对外部（用户、开发人员）暴露出来的元素，这跟软件对外暴露出来的 API 是一个道理。变体、封装就是一个个列表，电热等物理特性就是元器件与外部环境交互的函数，额定参数是约束条件，管脚是输入输出的参量变量，设计原则是约束方法的函数，推荐方案相当于软件的示例代码，AN 相当于社区内关于问题的问答总结分享。
这不是一回事吗？
咋了，文档都是给人看的，都是为了说清楚事物的，在这两方面，难道硬件和软件有原则性区别吗？

最后模仿你的回复来回复你，这是我最喜欢的环节：
我只是看到你只懂这么几样拿来显摆就泼你冷水，从你回复我也能看出你是啥水平，不管去没去过大厂，终究学点皮毛，玻璃心和少见多怪都能从你的回复中看出来。软件的文档你最多也就知道个 SDK，毕竟我都拿非 SDK 的情况来举例了，你还是只会咬着 SDK 不放，黔驴技穷啊，呵呵。
就要跟你细说，少说一句算我输，你不看有的是别人看，你 B 了是你自己给自己关上一扇门。

@shijingshijing #69
你 B 不 B 关我何事？ B 了别人还要专门说一声的怕不是羞愧难当给自己保面子哦。
我的回复虽然 @的是你，但是难道就是给你一个人看的？还勿念呢，这网站是你开的吗？你看或者不看跟别人回不回帖子有哪怕一丝逻辑关系吗？嗯？

我当然不是大厂出来的，我不仅没进过大厂，我连中厂都没进过，不、想、进。
咋了不进大厂就看不懂手册了？不进大厂就用不到手册了？不进大厂就没有硬件开发的需要了？
当年还在做工业交换机电路设计的时候，接触到的各种手册不少，有简略的有复杂的。
单是 marvell 一颗低端交换机芯片，pdf 就有小一百页，区区四五十根管脚而已，无法受外部控制，唯二的硬件配置方式是几根管脚拉高低电平，再加一颗 SPI EEPROM 。一路千兆八路百兆接口。
就这么点功能，marvell 虽然本身也不是大厂，依然详尽地写了一册厚厚的 datasheet 。你说的那些“管脚定义，时序图，电气性能，温度范围，物理封装等内容”不仅全都有，而且这些还依然不是全部。
关键差分线如何防护？核心方针是什么？推荐的设计方案是什么？关键部位电源接地平面的铺设需要注意什么问题？散热设计需要注意什么？时钟信号需要如何保证完整性？以太网接口和不同电平的远端接口如何匹配？防雷防护需要注意什么？等等等等。
这些只是一个非大厂工程师在设计一个用了非大厂芯片的产品时查阅到的资料、遇到的问题、学到的东西、积累到的经验罢了，和大厂当然没法比。
但我奇怪的是，你怎么丝毫没有展现出大厂工程师应该具备的远远超过我这种非大厂出身的人所具备的经验学识和概括能力，不仅如此，你居然用硬件手册上很常见的“管脚定义，时序图，电气性能，温度范围，物理封装等内容”来作为自己的论据，我看你也是空有头衔而肚里没货吧。
可惜你已经 B 了，没机会看你秀秀真本事了吼~

对了，我回复装逼的人言辞一向是比较冲的，这既是习惯也是策略，语气冲就像照妖镜，能把对面的真面目照出来。
我一没写脏话而没泼脏水，然后你一没立场二没论据，直接说把我 B 了，然后逃了。
嗯，你这是自描自黑。
太嫩。

（别扯什么 B 不 B 的，这又不是给你看的）

@shijingshijing #48

别在那自我感动，你看过多少文档？

芯片手册就两页 PDF 的很少见吗？

上千页的软件框架的文档在你看来很不可思议吗？

硬件有复杂的有简单的，软件也有复杂的有简单的。

硬件文档有写的详细的也有写的粗略的，软件文档也有写的详细的写的粗略的。

单一个多媒体编解码工具 ffmpeg，区区几十 MB 的命令行软件，官网上的文档如果下载下来一页一页打印成书，那玩意能砸死人。

然而 ffmpeg 的官方文档众所周知的“还远远不够详细”，众多的命令、变量、格式一笔带过甚至只字未提甚至开发组自己都说不清楚，就这样“粗略”的文档其分量已经让人望而生畏了，嗯？

“管脚定义，时序图，电气性能，温度范围，物理封装等内容”，区区这点内容，就让你感慨大厂的专业性和责任心了？


电子大厂那么多拳头产品，哪个不是除了一份已经“厚厚”的 PDF 之外，还有数不清的应用笔记？

看 datasheet 也就图一乐，真要解决问题还得多多查阅那些 AN 打头的官方应用笔记，里面满满当当的应用场景、设计样例、绕开产品 BUG 的方法、利用产品 BUG 的方法。都看过了？放心，看不完的，一辈子都不够。

那既然没看过在这儿嚷嚷啥呢？来装逼的？果然文人相亲吼，软件硬件不分家，要鄙视大家都在一根链条上吼？

有病！！！

软件文档是描述软件的，硬件文档是描述硬件的。软件暴露在外的是 API，自然要围绕 API 进行描述。硬件暴露给用户的元素难道不是跟 API 类同的东西？

软件的结构、原理、场景、变量、特性、语法、暴露出来的接口、接口接收的变量、接口返回的结果、接口抛出的异常、示例代码、推荐代码、缺陷、BUG 、避免 BUG 的方法、部署方法、运行环境、配置手段……等等等待。

对应到硬件的结构、原理、场景、物理量变化、物理特性、管脚、信号、封装、设计样例、推荐方案、可能存在的 bug 及如何避免、工作环境储存环境的温湿度盐碱度、机械特性、额定电压电流、管脚配置、通信方式、软件配置……等等等等。

来来来，纸和笔给你，我倒要看看你能在相同篇幅下把这些都写明白喽？

Datasheet 不就是硬件的文档吗，和软件 API 的文档有啥区别？

办公电脑硬件不拉跨直接虚拟机跑 Linux，宿主机占用的 CPU 可以忽略不计，内存占用几百 MB （ win7 ）或者约一个 GB （ win10 ），这点开销毛毛雨。

直接虚拟机所有加速开启，全凭或者远程桌面全凭，爽歪歪。

有路走干嘛要纠缠不休呢？