@Haku #17 不可以开端口，难道也不可以开 pipe 么？还有 IPC 通信共享内存什么的吧，也没说一定要使用网络才能搞 RPC ，windows 还有更变态的直接用进程 ID 远程写进程内存然后通过内核信号量通知进程执行远程调用的

便宜的越轻型因为弹性更大，所以噪音相对更大，你看健身房大型的就好很多，不过大多都超 5000 以上了，而且必备隔音地垫了

一种是像瑜伽垫大块的整体垫在跑步机下边，吸收你脚踏的声音，第二种小块的橡胶垫，垫在四角接触地面避免刚性连接直接传递噪音，可以垫个两三层估计更好，前者吸收低频噪音，后者隔绝高频噪音，如果跑步机放阳台估计楼下就不明显了

买过小米的跑步机用了很长时间，不过这货毕竟便宜踏板弹性太大，你几乎难以控制踏板回弹不和你脚下踩不相互冲击，对膝盖脚踝的冲击要比实在水泥地还大，后面膝盖疼的不行，所以还是废弃改室外跑了，真是受不住

厂商的请求数都是后算的吧，而且也只是个统计值，否则近乎实时计算每个对象的请求数这个费用估计都得超过你存储需要的费用了吧，所以没有这功能才是正常的

不会以为这种清理内存的程序不是通过杀进程的话就真的能清理内存吧，内存泄漏还是要程序自己解决的，程序正常改加内存就加内存呗

@sunorg #10 顺便补充一点点，这个写的 SQL 主要方向还是数据导出和数据同步，所以 insert into 并不和数据库的 insert into 一样，其 select 的第一个字段表示主键唯一值，insert into 的时候可以指定选项按这个字段值存在则更新否则插入以保证可重入，毕竟定时脚本统计同步数据不能保证重入简直坑死人，默认则是追加，如果是按天统计结果的也推荐用日期加统计类型来构建一个唯一值更容易保证不出错

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

那来推荐下这个项目呗，写 SQL 可以同时查询你需要的这些数据源还可以相互 join ，python 搞的，出发点也就是你现在遇到的这种需求，把统计结果同步到 mysql 之类的，图表用 superset 就很好用了

@fantathat 你这怎么还没转过来，你以为你发个图片消息实际内容是木马对方就直接运行木马了，这么明显的漏洞你是当大家都是傻子么，如果你在两边微信都能装插件你自己就是最牛逼的木马你还发个锤子的木马

如果按上面说的图片漏洞那是不是微信都会中招，你随便打开一个网页就中招了，但微信浏览器这种体量这么大的这种漏洞几乎不存在，否则早被人发现了

无厘头，如果你这能通，那我还有更简单的，我给你回复个自动预览的图片，或者微博什么的发个图片，但其实是个木马程序，那岂不是全部人都要中招了，这和你说的不就是一回事么

也许你需要的是 modbus 转 mqtt

比如这种 https://www.emqx.com/zh/blog/bridging-modbus-data-to-mqtt-for-iiot

慢慢来，身体要适应哪有那么快，慢慢提升距离速度，三月一周期适时调整，你这才开始呼吸适应了才怪，膝盖脚踝受不了了别强撑很容易受伤，差不多坚持跑步一年了才慢慢适应的，现在 6 、7 年了，你这才一个月别那么着急，运动贵在坚持不在于一天蹭蹭就要跑死

公布的驾驶速度不能算公开个人数据吧，个人数据很明显需要反向通过这个数据关联到你，但是公布的驾驶速度相关数据很明显并不符合，所以他们公布的这个信息肯定是不违规的

车联网这事本身不但车企很需要国家也有要求所以已经无可避免了，但也正因如此，社会、政策和法律都会有更严苛的监管和处罚，这对我们普通消费者算是好事了，毕竟都这时代了，按这么说手机只要接入基站，就会 24 小时每分每秒像移动运营商上传你位置等等各种数据了，但不也还是时时刻刻手机不离身了，你觉得手机安全，那么从相同的监管和处罚逻辑来说两者是一样的，无所谓顶多尽量选择正规大厂罢了

按驿站现在的模式根本没有拉黑一说吧，快递公司都是一股脑拉到驿站整车倒到驿站的吧

@batchfy #28 docker 私服也是一个镜像啊，docker run 就搞定了，也怎么耗资源，然后可以带私服 ip 和端口地址请求镜像就可以，不带只是镜像名称的普通操作还是官方镜像，挺简单的也很方便

@batchfy #11 docker image 分层不就是为了不需要后面再干一遍么，所以你是不是对 image build 有啥误解还是用法有问题，正常都是本地 build 上传 image ，服务器直接启动哪里来的需要安装 npm 和编译之类的，这不就是你想要的本地直接编译好服务器 copy 镜像直接启动么，正常的 docker 就是这样用的啊

@yellowmarlboro #4 数据库也是可以当作普通软件用的吧，mysql 什么针对特定场景优化配置其实内存消耗可以非常低的，容错了简单，本地库查挂了就再查一次主库就是了，再搞个监控解决了

@yellowmarlboro #4 其实既然都是备库了，sql 库无论 sql 执行效率和内存效率都是最高的了吧，你自己搞个内存计算的既不如数据库高效也不如数据库稳定，性能不够多搞几个备库节点就是了呗，网络消耗的其实无所谓了吧

更进一步其实可以直接在应用节点搞个备库就是了呗，或者用 sqlite 也行呗，没必要非要搞个内存执行 sql 吧

@realpg 首先合不合理是一回事，历史遗留问题为保持一致性不应该修改是另一回事，别说整个计算机体系里了，整个世界不合理的设计早就多如牛毛了，人家都告诉你 breaking change 还有啥好说的，所以啊就算你觉得应该有更好设计那现实的也是 featute 不是 bug ，你想修正它那也是在提新 featute 而不是提 bug ，接不接受那是别人的权利

@xxxyangyu #9 你这个是使用场景不匹配的问题吧，plc ，pxi 设备之所以这么设计协议估计就首先约定控制端在同一物理位置且通过可靠忘了连接，你非要弄到公网或者弱网下用，不单独添加设备侧得本地网关保证可靠性，显然是不能的吧

@XuanYuan 也许你用 openssl 连一下测试看看，估计就会看到发了 client hello 之后没啥反应了，好像一直有这个问题吧