adoal

天龙八部，牛鬼蛇神，他们的生产力和破坏力，都会被 AI 放大

别说小红书了，V2 也是一样

@meihan1997 其实就算 5 点下班，要做到晚饭能 6 点开吃都很难。至少通勤时间和烹饪时间要有吧。

“我是 5 点下班，吃完饭大概 6 点，刚刚好。有的时候在单位 4 点多吃晚餐”
这句话就是 V 站大多数人不具备的条件了。
甚至都不需要看互联网行业的牛马。
当代体制内的一般也都达不到。

因为白天要经常拍打那个“又一个傻逼来打扰我正常工作”的计数器，所以需要大脑的事只能排到夜里干。

紧凑布局必然存在“魔改”，无非就是委屈哪些键位罢了。你觉得这些是大问题，是因为这些键位（假设称为集合 A ）被委屈了。如果有符合你在这贴里提到的键位的魔改，那肯定会委屈别的键（假设称为集合 B ）。但现在没委屈集合 B ，所以你感觉不到。但如果有符合集合 A 的键盘在你手里，很可能你又会觉得集合 B 被魔改掉难受了。

所以 87 才适合你，不要追求什么紧凑布局。我就是 87 是底线。

typo 几乎没有的人，不一定技术能力强，但是至少做事严谨，那么从完成工作的角度看这也是一种竞争力。

你钻牛角尖了。前人遗留的部署屎山，不但屎，而且“不可知”，那么去做“验证”只会叠床架屋堆上更多层不可知、不可控的 ad-hoc workaround 屎。所以这不应该是一个技术问题。不要浪费你的宝贵精力做这种出力不见效的事。如果你有主观能动性，愿意从管理的角度去思考这个问题怎么解决，那就争取你的+1 甚至他的+1 的支持，对服务器的管理机制做治理。新上的用可控的部署方法，逐步滚动改造存量服务器。而不是争取领导支持来在屎山上做“fstab 的验证”。

更长远一点，应该对开发架构和部署架构做改造，对服务器节点的使用方式和程序访问存储的方式做优化，把各种不同类型（比如本地/NFS/对象存储等）的使用隔离掉，在架构上就把非本地存储的挂载失败作为常态考虑，把重试、容错作为设计的一部分。当然这样就超出你的职责范围，会动到别人的蛋糕。虽然未必不可行，但博弈更复杂，只有长期主义的+n 支持你才可行，也就说说吧。

感觉 [因为 mount -a 可能会把当前未挂载的文件系统真正挂载起来，也可能主动访问 NFS 、NAS 等网络存储，甚至改变当前系统状态。在复杂生产环境中，这种操作有可能产生额外影响，极端情况下甚至可能出现不可逆的问题] 这个现状的复杂性才是你问题的根因。可能还是得想办法把这种挂载操作的不可控给解耦隔离到一个较小的范围更合理吧。