而且看政策，城市场景中，这种必需在特定审核批准的起降场起降，后续需要沿着备案的特定飞行路径和高度飞行，低空空域也不高，估计顶多能规划 3 层的飞行空域，现行情况下估计几乎不可能有什么空中红绿灯，所以也必然需要起飞前就规划好不会和其它人冲突才能起飞，所以随时起飞，以及想怎么飞就怎么飞也是不可能的

@lei2j #3 也没用吧，相比地面通行来说，一线大城市这种级别同时上路的车估计能有几十上百万辆，但是能够载人的飞行器同时飞行的数量估计也就千级别，送外卖快递这种小型飞行器估计也就万级别，相比总需求来说真的不值一提，跨区飞行想法挺好但是因为不安全因素大幅变多了，通行容量和时效根本不可能太高，容量太低注定只能是奢侈品，大多数人看看就好了

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

@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 呗，直接挂载磁盘