还是建议优先考虑硬件解决，比如 PCIE 槽的 M2 扩展卡。除非你的“服务器”是 mini 主机那种，连额外的 PCIE 槽都没有的。顺便吐槽一下，虽然“服务器”可以是一个装在任何计算机硬件上的软件角色，不一定要像机房里的服务器那样各种高可用设计，但还是建议使用有一定扩展性的硬件。

如果实在没办法硬件解决，可以用装到你的另一台主机上来做。Windows 下应该也有办法的。不过更确定的办法是用一个 Linux live image 来启动，然后直接盘对盘 dd 过去好了，dd 完了修一下分区表（ GPT 分区是头尾双表的，dd 到大盘上尾部的表不一致，要根据头部的重建），然后挂回到“服务器”上，启动以后 ESXI 里可以把未使用的部分扩展到现有的 VMFS 卷上。

1. 你认为的计算机图形学具体是做什么的？
2. 你认为与会被 Sora 取代的工作具体是做什么的？
3. 你认为这两部分有多大交集？

@BeautifulSoap 不不不，他们认为的“事”跟“偏移量”根本无关。你说的““偏移量”无法解释为什么从 0 开始的哦”，首先真的是要来谈偏移量，在编程这个语境里，然后再谈认知从 0 还是从 1 开始的合理性。而真正的普通人，他们说的只是“数（上声）数（去声）时的编号从 1 开始”，他们甚至脑子里嘴里都没有出现偏移量这个概念，你问他（编程，或者非编程时排列在一起的同质物品中的）一个元素相对于首位的偏移量是从 0 还是 1 算，他第一反应你说的是什么鬼东西。

另外我还想说的是，如果写了多年代码，并且从 0 和从 1 开始的语言都正式使用过，那不论是认为 0“更”合理还是 1“更”合理都没问题，但这里的出发点是“更”，也就是说至少对两种方式的优缺点都有所体会，对各自的合理性都能认识到，然后再这个基础上再谈自己的倾向性。而不是依旧无法理解其中一种方式的合理性，只认为另一种合理。多年下来还理解不了的，恕我暴论，还是别做程序员了吧。

另外我想说的是，如果用下标从 0 开始的语言你容易写出 bug 来，换成下标从 1 开始的语言你一定还是会写出同样的 bug 。

如果你执着于把最开始的元素称为“第一个”，那就会在这事上纠结死。称为“头部”即可不在乎人类的序号规则，平心静气接受用元素距离头部的偏移量作为索引。

@BeautifulSoap offset 是相对于 base 而言的。0 表示距离 base 为 0 ，1 表示距离 base 为 1……如果 head 元素偏移量是 1 ，那 base 是谁？在 head 之前强行引入一个 pre-head 作为 base ？
普通人意识里的从 1 开始，不是 offset ，而是 ordinal

不分类

自己在树靶子打吧。

如果不是从功利的角度来看，“对配环境乐在其中”挺好的，至少有个自己的乐趣方向，比那些自己毫无兴趣也毫不擅长只是因为一个行业在风口上就挤进来的阿狗阿猫好多了，哈哈哈哈。

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

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

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

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

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

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

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

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

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

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

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