@amajia #1 -L 端口转发是很好用，-D 能开 socks5 代理，唯一美中不足就是不能开 http 代理啊，但是端口通过另外一台代理服务器转发到远程服务器有时还是很需要的呐

设置路由，配置 nat 就是了啊，用 route 和 iptables 命令加下就好

@lxrmido #4 我这开机了三天，那么每天写差不多 10G 了，真是比想象得多得多啊

@lxrmido #1 没啥场景，就看常规使用，浏览网页看视频工作，其实直觉一直以为会读远远超过写来着

既然如此，这么多软件都可以开模拟盘，还费那劲干嘛，虽然吧 1 万块本金和 100 百万本金其实是完全不同的

dict 的 key 啥时候能重复了，你这是犯傻了还是想要逆天无视数据结构规则了

@amiwrong123 #4 不是 2 的幂，你可以查一下大部分分配器的实现，大部分都是 2 4 8 16 32 这样分配的，倍数，虽然会浪费一些内存，但是内存碎片少，分配管理效率高

内存对齐，还有现在大部分内存分配管理器都是 2 的倍数分配的，不这样处理那就白白浪费内存了

虽然读写起来是少了很多事，但是对于大多数业务来说，这也代表着逻辑不清，定义不明，结构不合理，缺少足够思考和理解，这不但脑懒还手懒，从维护来看真的是作死，如果经过了细致思考梳理设计，那么就应该每个字段每个数据定义逻辑都应该清清楚楚明明白白，既然如此那又犯这懒何必，借助良好的 ORM，使用上还更简单，关于性能不性能的，纯属想太多

@opengps #1 但是事实上说的全是错的，纯属啥不懂还瞎 BB

分布式 ID 大多都是 Client 本地生成，算法基本逻辑大多是一样的，看最终字节数吧，8 字节估计大部分情况都需要手动配置 clientID，也就是集权机器进程 ID，16 字节一般也就可以直接本地取信息自动生成了，除此之外很多情况下还有希望是直接数字时间，比如订单号这样比较容易给人看的，但是这样的话直接占了 14 字符了，所以很多时候还是需要依据自己业务量来适当调整的

@iptables #19 看师傅的意思是看路由超级密码的权限被收回了，他们改啥都是和客服说，啥权限没有

江苏这边师傅修改的权限都被收回了，他们居然也是找客服改的，然后远程自动下发，上次给公司拉宽带，师傅担心光猫带不动这么多设备，想改桥接，在那找客服鼓捣了一天都没搞定，真是服了个服了

所以那么打客服应该也可以的吧，不行就让师傅帮你找客服

错漏百出，这都敢出来胡说八道，真行

首先 mongo 的 ObjectId 是本机生成的，谁说要写入库才有的，而且是单调递增的

分布式 ID 的首先需求是区分不同进程不同机器，不同机房，好嘛，直接把时间 bit 数加上去了，区分机器进程能力完全丧失，而且实际使用过程中，生成时间并不是平均的，有可能其中一毫秒内生成了几万几十万接下来好几小时都不用了，单毫秒内计数单字节，作死啊

Snowflake 需要手动配置集群机器进程 ID 作为一个分布式专用唯一 ID 生成算法就已经很不方便了，完全让一个微服务分布式系统无状态依赖变成了有状态依赖，而且是一个非常重要的依赖，作死啊，但是算法限制字节数 8 字节确实没用更好方法，但事实上强行限制字节完全没啥意义，多增加的成本并没有多少，但是一个完全无状态依赖又安全的分布式算法对于微服务分布式系统的意义就大多了，不知道省了多少事多少心

所以不清楚不知道还是别出来误人子弟瞎 bb 了

据观察，考试的车如果看着不咋滴发动机比较弱，所以起步时如果先少放点离合接着放刹车略微给油，提高点发动机转速再放离合可以大幅度降低熄火概率啊，但是考试时你还得协调的过来，当时教练死活说的是先放离合到车身抖动放刹车简直被搞到死啊，动不动熄火，后来才发现这车太破教练自己放离合也给油

大部分情况来说，代码真不值钱，值钱的代码都是靠专利和知识产权保护的，所谓跑得了和尚跑不了庙，重点是云厂商别存在啥漏洞可以被第三方获取就好，而 Serverless 再多个账户间应该是完全隔离的，你不用担心运行的过程中被其他代码复制了，思维还是要换换啊，别老是代码代码啥的

而且吧 Serverless 倾向于专注高性能免维护小服务，基本单一部署的不具备啥完整性，你弄过去也用处不大啊

从物理学来说，无线带宽越大的必然频率更高，然后穿墙能力越弱，满负载传输距离也更近，城市高楼的话还有无解的热点太多干扰问题，乡下没啥干扰还好点，有线则有这空间内更高叠加的优势，所以一行就算发展也应该时更多近距离更快无线 ap 节点才是，无论怎样都是有线更靠谱啊

其实吧，如果空间够，距离远各卧室似乎也没必要从弱电箱直拉啊，在楼上楼下再加交换机分就是了，带宽也足够了