centos8 等得好辛苦

@lolizeppelin #51 恩，bug 变多对普通用户没有影响。系统配置方式改变对普通用户没有影响。所以普通用户是啥用户啊。

只说一个，11 年有个老项目，当初从 centos5 升到 centos6 略有一番折腾，随后决除了安全补丁外，基本不动它，用到现在。对了，明年可能不得不去折腾下，或许一步到位到 8。当然，收钱是必须的。

用 python、ruby、php 之流才会对 centos 怨念那么重吧。不过，容器化的今天，似乎也没有怨念的必要了。

很有意思的是，看人家对 centos 的怨念，大体能看出他做啥范围的。

@msg7086 #56 还是你们开发水平太太太太菜。既然要依赖其他特别高层的软件，ruby、rails，你肯定要去用他们上游的版本，上游的长期支持版本（如果没有，只能自己内部维护一份或者联系第三方维护），那有拿发行版源里版本用的，发行版保证不了这些特别高层软件的兼容。既然拿发行版版本用了旧做好和发行版完全捆绑的准备吧。

然后源码树里放一个 third_party、package、之类的名字，然后构建系统直接全部构建了。（不是要你编译安装 ruby 这些软件，而是将你的软件使用你自己的 ruby，你自己编译的不安装到系统，统一打包进你的软件）

想升级这些依赖，基本上就是 bump 一个小版本号，然后重新构建就完事了。

RE: “官方 backport 包也就是把新 Release 的包在旧机器上重新编译一遍，本质上都是一套东西。”

这正好印证了我说的这句话：通常来讲，如果软件写的时候就符合规范，切换系统直接在新系统上编译一遍就是。Linux 内核从不来打破 API 和任何已有的标准、假定，发行版也几乎不打破 API 和假定。ABI 变化是可能的，因此只需要编译一遍。

@LokiSharp 各种不会用啊，从 debian 系转学生

@crystone #64 有啥不会用的，所有软件源里有的就装源里面的，别自己乱编译就行了。实在要用的绕不开的 Docker 里面用 Fedora coreos 作为容器就好

@iwtbauh 我们系统开发的时候，Ruby 连 Gemfile 和 bundler 都还没发明出来，更别说 docker 这种晚了几万年的技术了。Rails 那时也是刚出来不久。有些问题不是拿十年后的想法就可以解决的。否则车管所也就不用抱着 30 年前的小型机一直用到现在了。（是的，我们车管所至今还在用 30 年前的 Mainframe，离用上 x86 的服务器还有很多年的路要走。他们已经花了 10 年的时间在迁移了，还没搞完。）

自从 Ruby 1.8 到 1.9 的更新直接炸穿了整个社区以后，麻子他们自己也不敢这么瞎瘠薄搞非兼容升级了。
Rails 1.2 到 2.0 的升级也是如此。
要是我司当年就能享受到现在的技术，也不至于项目搞成这样了。

用过 centos 7 和 centos 8 Java 开发的，服务器上感觉一般般，无非就是一个 jdk 搞定，实在不行，自己弄个可以执行的二进制文件，一直对 centos 抱有好感，直到有一天我闲着没事，把个人电脑转成 centos 作为开发，在那以后对 centos 评价

e....mmmm 太老了，还不如 Debian


centos -> Debian -> Arch -> Manjaro

PS: Ubuntu 就算了，不是很喜欢

@nnnToTnnn 原谅我为啥选择 manjaro，主要是双显卡驱动搞死我了。。。

此时一名用 Debian buster 的靓仔路过 :doge:

@saytesnake Cent 戏粉这么足的🐴？

@msg7086 感谢这位

@lovedebug 6 也还在维护期内，有什么安全问题是很难处理的？不是直接 yum 更新就行么（新版里相关的 patch 会被 backport 回去，所以源里的应该都是会修复的）？

总感觉 Centos 就是一种没钱也没精力维护的妥协。这种妥协的替代品很多啊。
个人而言，最后用啥都无所谓，只要 cloud 支持就好了。

@msg7086 #66 emmm，你没看懂我的意思。我说的是这些软件不应该用发行版的版本，应该随项目构建，做好构建系统后基本上就是多写个 Makefile 的事...升级就是改下 Makefile 里的小版本号。和 docker 有什么关系，用不着 docker。也不用关这个软件内部的东西。

@iwtbauh 随项目构建也没的人来打补丁维护啦……另外还有很多和系统绑定的东西（比如我们用到了偏门的内核模块），也不是很简单能随着系统更新的。

你说的也不算错，当时要是选型的时候能再稍微多纠结一下的话，可能会有更好的选择。但是 2006 年的各位也不见得在 2006 年就会做出正确的选择就是了。

@msg7086 稳定性和长期支持 ——> 万年不更新的老掉牙版本

@est 万年不更新的老掉牙版本 ----> 万年不升级的老掉牙版本

@msg7086 #75

“随项目构建也没的人来打补丁维护啦”，我说了好几次了呀，Makefile 里改个小版本号，你比如现在用的 1.2.3 版本出现漏洞，升级到 1.2.4，然后我只需要改一个版本号变量然后输入 make，然后喝杯咖啡就行了。

“另外还有很多和系统绑定的东西（比如我们用到了偏门的内核模块）”喔，我实在想象不出你们什么业务需要用内核模块，不过也很好解决呀，构建的结果不一定非得是二进制文件，高级的源码也是可以自动生成的（这也是为什么世界上会有编译器这种东西），你们的开发时直接将内核模块源码构建成 dkms 就可以了呀。

我简单梳理一下，开发机源码树分成多个部分，构建到一个 build 目录，build 目录中会有你们的业务代码和部分依赖的二进制，还有你们的输出成 dkms 的内核模块，然后构建系统自动把 build 目录打成 deb，然后上服务器只需要 dpkg -i 一下，什么不靠发行版的依赖啊，还有内核模块一键搞定，还可以发行版升级内核自动重新建立模块。

2006 年的 Unix 系统程序员要是没有这个水平，新手就算了，不是的话建议裁掉重新招人。

@iwtbauh 我们业务啊，涉及到一些虚拟机方面的东西，要和 Xen 交互，要产生一些虚拟的块设备，然后要把块设备从 NFS Share 映射出去，反正挺乱的。
2006 年反正那时候我司只有一位物理学博士创始人负责管理软件开发，从头开始学起的，还是不难为他了。

话说这跑题有点远了……

看评论，变成了圣战场……

Linux 的优点在于提供了足够高的灵活性，每种发行版都有自己的风格，但也都不是死的，根据实际需求各取所需就好了。