赤足跑脚弓承受的冲击肯定更大，膝盖的冲击力肯定也更大了，毕竟城市里跑，用跑步机也好还是塑胶跑道，缓冲都毕竟小，而且基本完全平的冲击力太固定，这样还是很伤的，最好还是穿好一点的跑步鞋，有时间也要跑一跑凸凹不平的土路啥的，有助于保持关节受的冲击平衡

说起来今年估计完成 95%锻炼吧，不到 600 公里，基本只跑 15-20 分钟了，膝盖真承受不住，改 30-40 个俯卧撑蛙跳和 60 个左右哑铃了，其实习惯了并不累，而且不锻炼还感觉身体很重浑身不舒服，也别在逼自己吧，贵在坚持

@msg7086 #10 10 楼说的对，这种十分基本的函数会有针对不同平台、不同 cpu 版本、不同指令集的对应汇编级实现，汇编的实现函数会在上层用宏来定义，你找不到具体实现可能是 ide 不能识别汇编函数定义，而且有可能不同版本的汇编函数定义过程是不一样的，很难找的，其实这个函数语义很简单，你不用管不用怀疑具体实现怎么做的吧，真想了解似乎你直接编译后 objdump 看汇编代码更有意义吧

中小型项目这个问题真挺难解的，实际项目中，统计需求基本难有规划，基本需要啥你就给我出啥，这个主要还是一般产品似乎都搞不定这个，运营知道要啥数据但是基本也搞不定组织规划的问题，大多数公司基本又觉得专门的数据开发岗多余，确实不好解决，此外不重视自然研发这边难有统一规划，比如写个脚本不管出错重入啥的，所以啊，想要做的好，就得重视按正常产品流程来，独立的数据统计项目，不仅看眼下需求，要做良好得分层设计，完善的出错恢复监控流程

其实统计和正常产品两个逻辑是很不一样的，不应该在同一套数据表上实现两个逻辑，当然很多人觉得平时需求开发都完不成，哪有功夫仔细规划，其实如果仔细想想看的话就发现这个并不会花很多功夫，数据只要做好了数据拆分重组的逻辑，剩下基本都是数据同步的过程了，逻辑简单很多，平时多注意点，慢慢 bi 的逻辑也就建立起来了，否则就只会越来越乱

之前我们的项目也这样，简直坑死，搞到后面数据需求多了，感觉一大半时间都是在导数据，太折腾人了，但是慢慢注意了一些，其实好很多，之前做过一个项目，用 json 来定义数据同步计算过程，其本身也限制了一次只能同步一层的数据，既是限制也是规范，算是参考吧

https://github.com/snower/syncany

服务发现除了要能找到，异常、故障、宕机了也要能让使用方即使知道踢出该节点的啊，这可是双向的，不是单向的啊

gre 组网如果放在网关上是不能和两个机房在同一网段的，否则会冲突，除非你在每台机器上都配 gre 隧道，这种且不说维护难度太高，而且好好的千兆万兆内网非要搞个隧道，网络性能白白损失你这是要干啥

再说用 C 网段的话，不是每家公司只会有一两百个节点的，用 A 、B 网段可以组件更大网络，但是关播流量是不是太高了

最好 mdns 作为系统级服务，也就意味着不止你一个服务会用这东西，其可控性可预知性是不是太弱了，大型分布式系统都是要求高可用高稳定需要持续服务的，你这不是给自己埋坑么，分布式系统都搞出来了，搞个更可靠的服务发现过程又不是啥难事，为啥要用 mdns

其实这种要是有个有格式的部门编码就好了，比如用 bitint 保存，用 18 个数字作为部门编码，每两个数字组成一个部门 ID ，共可以有 9 级，每级最多可以 99 个部门，一级部门在最前面，后面部门依次往后，不足 18 个数字后面补 0

比如：

一级销售部 010000000000000000
一级研发部 020000000000000000

二级销售-北京 010100000000000000
二级研发-java 020100000000000000

三级研发-java-linux 020101000000000000

这样查询子级部门啥的就是个大小比较，很方便，新增修改部门也不算麻烦，如果想级别更多，那就搞两个 bigint 字段似乎就行啊，同级别 99 个子级部门估计够用了吧

@tabrye #93 你到大街上随便找辆电动车都可以嗖一下到你前面，这个完全是因为电机响应远超内燃机，好多燃油车超不过去的电车都可以轻松超车，就看你胆子够不够大了

这不就是 ipfs 么，事实上 p2p bt 为啥越来越不行，不在于技术本身，问题来源越来越多的云服务提供了更可靠稳定的服务，大量小白用户根本就没需求，剩下那么点用户可用性太差几乎没啥存在的价值了，再说现在知识产权保护这么严格，普通用户还有何价值非要用这种方式存文件，未来肯定是 ipfs 这种了，但参与者必然是数据中心，数据和算力需求会持续增长，数据中心数量未来会非常多，那么这个说白了就是数据中心金融化的过程，构建强大的商业属性和金融属性才是可以持续发展的最大动力

电车几大件，电池现在主要是松下、LG 化学、宁德时代、比亚迪，但这个提供的可都是解决方案，整包电池，产商能做的其实不多，氢电池的话似乎日本更强一些，毕竟投入都不够

电机的话现在电机效率都 98%-99%了，做的在牛逼你能提高 1%已经牛逼上天了，现在主要优化的是地中高功率小的扭矩和电机热控，特斯拉电机 2 转以上，国内各厂差不多 1 万 5 ，主要就是热控的差距了，似乎这也导致百公里加速大家都差不多，但是持续时间可就大不相同了

自动驾驶似乎现在大家都转型深度学习这一套了吧，不过明显国内走的还是慢一些，硬件的话固态激光雷达华为在搞，似乎也没有听说特别便宜成熟的，估计不是各好方案，算力芯片其实国内也有在设计，后面估计就是 risc-v 这个体系了，国内好几个大厂在做了吧，看起来进度也不慢了吧

剩下就是整车车架、悬挂、内饰等等相关的了，个人感觉这个就是产业投入的问题了，有投入自然能做出好的，整车电气化的话老车厂反正也是做的一塌糊涂没啥好说的吧，之前不是有传统车报整车电气化代码的么，也是不忍直视的吧，不过本来对于传统车厂来说既不重要也不擅长吧，这个现在似乎看不出谁更牛逼一些，特斯拉这个刹车搞成这样，其实也可以看出，现在的整车电气化真是一塌糊涂

电车差不多也就这些了吧，个人还是偏乐观一些的，做的是不是最好的不一定，但是吧完整体系是建立了，不说现在最好的，说个第二第三个人觉得还是可以的，别那么悲观，时代不停在发展，太悲观很容易错失机遇啊

@blufaux #25 你这就不科学了，电池厉害，那么电池热管理能耗管理系统一般就是电池厂商做的了，电动车电池厂商可不是只做原始电池的，电机不用说了，效率本来就很高，做的再好估计也就 1%效率差距了，不过扭矩电机热控啥的还是有优化空间的，自动驾驶就不用说了，从测试看特斯拉似乎更强一些，但是就现在来看这个体系本并没有想象的那么难，国内几个大厂看起来也没有落后多少

其实似乎大家也别那么悲观好吧，电车不比燃油车产业，至少眼下看整个产业链还是走在比较靠前的，软件产业体系更不用说了

@v2yllhwa #4 现在操作系统装好自己就有几十万文件了吧，不算啥吧，别放在一个文件夹下就是了，再说你可以搞个分布式文件系统啊，hdfs 、fastdfs 、JuiceFS 之类的

@chi1st #15 似乎江苏电信这边已经不行了，保修师傅上门啥也改不了，有问题他们还得在他们那啥 app 上找远程客服帮忙修改

@z7356995 #1
@chi1st #2 这个现在似乎不可行了吧，现在几乎都改成远程控制了，超管密码维修师傅都不知道了

既然可以稳定，value 又是只增加的，直接存成文件就是了呗，一个 key ，一个文件，数据直接 append ，这多快多简单，也不会不稳定，没啥必要用啥数据库吧

@LeeReamond #15 win11 的 wsl 已经可以装了，主机和 wsl 都能同时识别出显卡来了，tensorflow 跑起来很正常

@jbue520 #2 调路由优先级啊，网络基础了吧，如果在本机的话也可以打开 socket 的 bind 到对应网卡上去

如果云主机买的公网 ip 这种的话，以上两种方式就不行了，但是云主机后台都有设为出口 ip 这样的功能吧，你可以找找看

话说把所有 ip 都加到白名单里就是了，干嘛这么纠结？

不是 Authentication failed ，mongo 每个 db 好像授权单独设置的吧，不加 db 其实是有个默认值的，好像是 test 还是 local 来着，估计单独指 db 名的时候用对应 db 来做鉴权了吧

这写的有歧义吧，主线程完成的是 epll 事件以及命令处理，线程池完成 socket 读写级命令解析，所以主线程阻塞的意思应该只是转入 epoll wait 了，这种其实也只是针对你只有一个 socket 连接到 redis 的情况，多个连接下主线程当然是该干嘛干嘛啊

不想自己配就淘宝直接买一对单线复用交换机呗，价格也不算贵