看来题主没有遇过什么绊脚石,这样吧,我就结合自己的经验跟题主唠唠嗑两句。
首先,对于初学者或者打算学习Linux的童鞋,当然选择最新版本来上手最好。这点是毫无疑问的,不选择最新的,难不成还要选个淘汰的?
但是,对于工作上、对于企业上,却又不是那么一回事了。可以说,企业技术跟最新技术一直都是一对不可调合甚至互斥的关系。这个我打算列出以下几点来详说:
1、这并不是说什么开发大爷太懒或者运维大爷太烂,而是现实往往太残酷了
学习的时候,环境一般都是实验室化(理想化),所遇到的问题也相对简单。而真实的生产环境中,环境一般更加复杂,所遇到问题也复杂度也往往百倍于学习时所遇到的。这个时候,就来不得任性了,必须要循规蹈矩来。
2、既然现有的环境没有问题,为啥还要换
小米5已经出来了,那正在用小米1、2、3、4的用户,是不是应该把当前的手机扔掉,买一台新的小米5呢?这很明显是不可能的,又不是钱多人傻,为啥要把好端端的手机扔掉买一台最新的?结合到生产环境中,当前的系统都已经稳定的运行,为啥要扔掉再装一个新的?!
什么?新系统会修复bug?这个bug不关我事,我的系统一直正常运行,明显是没有踩这个bug的。爪洼8发布了,我作为一个Haskell的开发者,没理由跟着欢呼吧?
3、换系统往往带来潜在的风险
一个程序要正常运行,不仅要求自己的程序没有问题,还要求他依赖的软件包没有问题,而开发大爷们所开发的程序往往都引用了大量的其他程序包,有得还调用了不少的操作系统API,万一他们出了问题呢?这里我就分享下自己的两个伤疤好了:
伤疤一:答主以前还在读书的时候,开发的某套系统,已经在线上跑得好好的,后来某老师把这套系统卖给了某学校用,结果上线了之后,发现运行报bug了,分析之下发现环境变量“__PUBLIC__”解析出现异常,通过两天的排错,答主发现这是运行环境不同所引起的,答主的环境是“5.3.9”,买了这套系统的学校环境是“5.4.0”,看起来似乎就差了这么0.0.1个版本,细查该软件包源码后天杀的发现,有一个函数的实现被开发者们改了,再调用这个函数的话会输出另外一个结果。
伤疤二:答主以前在make “libgdiplus 3.x” 的时候,抛出了一个Error说某个依赖包版本太低,需要更新(比yum中最高版本还要高),然后答主通过源码的方式编译更新这个依赖包,没想到这个依赖包又提示其他依赖包不够新。。。。。就这样,答主最后把gcc、llvm、glib都用源码更新了一遍,最后的结果就是:原本正常的其他程序变得不正常了。
换一个软件包所带来的风险尚且如此,那还一个内核呢?可想而知了。
4、项目最担心的就是out of control
项目是不断壮大的,代码量会越来越多,结构也会越来越复杂,很多中型或者大型的系统都是一个大的团队,持续开发数年所诞生的,代码量十万行算少,百万行不算多。而这种项目一旦失控,那后果是不堪设想的,说白了就是,即便出bug了,光查都查死你。而像3这种情况,简直就是自作孽不可活的典范。因此,一些大的公司诸如腾讯阿里都会对某些重要的软件包或者操作系统进行自维护,就是为了减少因为“某函数被偷偷改写了”所引发的灾难。
5、出问题了,这个锅谁背,这个bug谁调
好了,前面的1、2、3、4可能题主完全还一脸茫然,这点就最直接了。出问题了,谁背这个锅?半夜出现了系统报警,谁来起床秒登VPN解决?12小时内修复这个BUG,谁自然为有能力在数十万行代码中游刃有余?
没有
没有
没有
重要的事情说三遍,除了傻子,没有人想自找麻烦,即便你多么勤奋,即便你多么努力。你的勤奋和努力完全可以用在学习上,而不是自找麻烦上,不然这就不是情商的问题,直接是智商的问题了。
手码字,好累,同意的请给个“赞”