1. 来自于互联网大厂实践升华出的现代运维方法论，跟传统运维差别很大。当然，能用得上的场合也少。很多传统行业的信息化里基本上是用不到的。
2. 开发的天花板比运维高是毫无疑问的。当然去大厂做 DevOps 、SRE 还是比传统运维有技术含量多了。
3. 学历是求职里重要的敲门砖。但是拿到工作之后的实际工作，研究生没啥必然优势。这些做啥都要硕士起步的根本原因是供需关系，所以弄一个超过实际需要的岗位要求来做门槛。

从几开始都是浮云。甚至有的语言可以自由定义数组实例的上下标范围。
相对于下标开始的数值来说，更有讨论意义的是，表示一段离散区间时，结束位置用 inclusive 还是 exclusive 。

Intel 64 是个市场说法，技术里一般不小写+连写成 intel64 作为一个 arch id ，只有 amd64 （纯技术）和 x86_64 （市场中立的改进）

其他测速站试一下吧。怎么看都像是这个 gdcn 测速站的问题。

讨论这个话题，我觉得应该先界定清楚，是说杭州的餐饮业，还是说杭州的本地菜系，否则就是一群鸡对一群鸭。

@adoal “极度不信任上下游”，我想说的意思是，同一个项目里不信任上下游的其他团队，甚至同一个团队里不信任上下游的其他角色。比如设计接口的人担心写业务代码实现的人没有安全意识顺手打 log 而 log 又会被运维的人随处乱放不妥善管理，所以传到业务逻辑实现处的信息先混淆或变换掉……特么的这不应该是团队治理要管的事么？当然现实中也确实有很多单位里做信息安全的部门是管不动业务部门信息化开发的，所以只能做各种渗透扫描、跨网段封管理端口和数据库端口、监听明文协议里的口令字段检查睿口令，然后发一堆整改报告等等。各种脱裤子放屁的扭曲安全设计，不一定对实际的安全有多大提高，但是对付安检倒是真的清净了。

关于这个屁事，我就说一个看起来像是空话但估计很多程序员甚至很多安全人员都理解不了的结论：安全是一项多环节、多方位的系统工程，同时安全性又只是衡量信息系统的指标之一。如果不能用系统工程的方法来整体做安全，结果就是每个环节的草台班子都从“别人是比我更不靠谱的草台班子”的视角出发，极度不信任上下游，用各种山寨的、同时又是过度防御的所谓安全措施来把系统拖得无比复杂，影响业务可用和产品可维护性，并提高成本。

这不说日经话题，算月经话题是可以的了吧。

@print echo 不加-n 会多一个换行

三十几岁的时候经常做考试梦。

现在最主要的噩梦是需要给人打电话或者地图导航的时候手机卡顿，触摸屏反应不灵敏，软件界面失常，在焦急中醒来。

一个软件系统里真需要高频随机读写，不能日志化的操作，其实不会很多的。

把软件架构里部非随机、非高密读写的存储功能放到对象存储，大概是最具有可操作性的云原生化了。

自己打，用穿孔头，或者六类分体式头，成功率很高。

在 300 人民币点位卖出了 100 多个靠显卡挖到的原始比特币的飘过，表示人赚不到自己认知之外的横财

魔障

经常见到这种问题。有一种文科硕士写论文前做调研的感觉。

明确称自己是 AP 的 AP 都可以。称自己是子母路由、mesh 什么的，鬼知道。

敝帚自珍，丑人多作怪