高价值货运和有钱人玩具，和普通人关联不大吧，毕竟空中通行容量比地面低太多，这么低通行容量下什么送外卖送快递通勤什么都是扯淡，只不过现在毕竟空白，行业还是可以发展一波的，只是天花板太低，爆发增长大多数人能收益估计不大可能，好看不中用的类型

@ysc3839 #16 这和你上面说的有冲突吧，读写都需要进入 native 啊，js 并没有在语言层面提供一种一定保证 fd 引用的方式吧，否则如果有这种可靠方式那就不需要你说的这种 dup 啊，而不能可靠引用的问题主要是因为 callback ，进入 native 执行的 callback 可能在 js 层面失去对 fd 的所有引用完全是可能，同步调用的语言就没这个问题，毕竟 native 返回前栈肯定保持了对 fd 的引用

@libook #12 比如各种 fd 传到 native 读取数据去了，之后通过 callback 回传，你 callbak 函数很大可能并没有引用 fd ，那就是此时 fd 可能只被 native 使用了，应用层并没有持有 fd 是不是可以被 gc 了

@ysc3839 #13 每次 dup 可能有性能问题不合适，毕竟文件 IO 可能非常频繁

量化算法只是一小部分，毕竟玩这个的都是顶级聪明人，规则又在那，真能搞出一个别人都不知道就你能挣钱的算法那不是白日做梦么

你去真玩一下就知道以上基本废话没啥用，要这么简单策略就能挣钱大家还上啥班啊，就算历史数据回测看着还行也意义不大，具体为啥你真金白银搞个几十万进去玩一下就能体会了

同感，特别是服务端都是单 module 小项目，idea 打开项目构建编译那卡的，而且比 maven 耗资源多多了，就算放到 ci 服务器上也比 maven 慢很多，而且对通过启动在 docker 容器构建编译一点都不友好，都也还得再 ci 宿主机去一台一台设置好各个版本的 jdk

还有个毛病就是如果同时使用不同版本 gradle ，ci 服务器会同时存在多个 demon 进程，分分钟撑爆服务器内存，不知道大家都咋解决这些问题的

不过说起来你都收到解码了，转码换更低分辨率确实毫无意义吧，分辨率低搞更高分辨率除非用最近搞出来的超分 AI 算法，否则毫无意义吧，所以既然发送端不支持改分辨率改码率，你这个需求本身就毫无意义了吧

接收端修改的意思应该是向对方发送申请新分辨率的视频流吧，应该不是让本地转码改变分辨率吧，看你这情况对方肯定不接受啊，所以显然改不了，视频分辨率不重新转码应该是改不了分辨率的吧，否则各大视频网站也就不需要为每种分辨率在服务端提前转码并单独保存了，或许你应该在收到视频流后先用媒体扩展转个码再发送给 video 标签吧

@yustation 就 iptables 呗，可靠性和性能都没啥问题啊，不方便用也可以搞个端口转发程序也行啊

@yustation 主机内部端口 rewrite 就好吧

有啥需求要这么干？

只同步数据的话那分享下项目

https://github.com/snower/syncany-sql

把 SQL 当作脚本执行，内部有自动依据主键增删改同步数据的逻辑，可以用 crontab 来调用

set @use_output_type='UPDATE_DELETE_INSERT';
insert into `pg2`.`adata` select `id`, `name`, `create_time` from `pg1`.`bdata` where `id`>=2;

使用 set @use_output_type 设定更新目标库方式，可选值有 INSERT 、UPDATE_DELETE_INSERT 、UPDATE_INSERT 、DELETE_INSERT ，不设置时和正常 insert into 一样默认 INSERT ，select 的第一个字段自动认为是主键，相同主键执行 update ，否则插入

大概率不能，串口就没状态线

nfs 呗，直接挂载磁盘

@chaleaochexist 可以这么认为，数据层是对数据准确、严谨并且完整无歧义的读写封装，理论上不应该和具体的需求场景上有关联，虽然吧数据结构完全是按产品和业务需求来设计的，但在软件分层架构中按产品和业务需求设计完数据结构后，我们却首先应该抛弃产品和业务的具体需求和场景，完全按照数据结构自身来设计标准数据读写封装层，而且吧现实情况下太多时候一个具体的产品和业务需求可能只有一个数据读写，如果没按标准分层架构设计，后续一部分变更需求逻辑后，很大可能就越来越混乱一塌糊涂了

数据层和业务层不难区分吧，数据层主要封装的是对数据结构逻辑的读写，这个包含着完整数据逻辑，大多数情况下一个数据逻辑只有一个读写操作，但有时候也会有多个，也许层对应的自然是现实需求和产品表达的具体实现了

举个简单例子，判断是都是超级用户这显然是一个数据逻辑，在用户登陆成功后需要判断是否是超级用户提示不可用这显然是业务逻辑

数据层不应该对应使用场景，而业务层必定应该对应具体使用场景，就这样啊