@raysonx
> Stream 虽名为滚动更新，但其实和普通的滚动发行版不一样，只是不再区分 8.1 8.2 8.3 这些子版本而已

问下以后 RHEL 出 9 后，CentOS Stream 是搞一个新的 CentOS Stream 9，还是继续滚动？还是说 RHEL 以后也滚动？

再举一个例子，RHEL 有编写的非常好（可以说是最好的之一）的用户手册，原先 CentOS 内部培训的时候，直接拿 RHEL 的手册即可，非常的详尽清楚。CentOS 自己的文档只有一个安装手册。

现在 CentOS 在 RHEL 之前，那部分功能可能就和 RHEL 不同，这事就麻烦大了。

感觉你可能对使用 CentOS 的公司或者组织的动机有所误解。

选择基于社区的免费发行版的思考不外乎几点：

1. 发行版的 Bug 特别是安全问题修复速度
2. 发行版的社区强大，有问题可以依靠社区解决
3. 发行版有很好的商业版本，碰到的问题商业版本都有，能够蹭解决方案
4. 发行版功能稳定，有非常良好的测试

CentOS 如楼主所说，存在 1 上的问题，但是如果要 Bug 修复快，为什么这些组织不用 Ubuntu 或者 Fedora，何必守在 CentOS 上呢，主要是看中了 2-4 。

原先 CentOS 是 RHEL 的下游，也就意味着 CentOS 有的问题 RHEL 也有，解决方案可能已经有了。而且 RHEL 商业用户相当于小白鼠，给 CentOS 的人来做测试，

现在 CentOS 是 RHEL 的上游，那就意味着 CentOS 有的问题 RHEL 没有，需要等待社区解决；然后虽然 CentOS 的软件包依然会经过 RHEL 的测试人员测试，但是其相当于 CentOS 的人做小白鼠，给 RHEL 商业用户做测试。

本质上就是原先 CentOS 的地位甚至高于 RHEL 的地位，虽然获取更新慢了，但是软件包都是经过 RHEL 的商业用户们先在生产环境测试过的，现在反过来，自然很多人不爽。

最后一句，在考虑稳定性的公司上是不可能使用滚动发行版的，必须有大版本锁定机制才行，否则会出大乱子。

@dengji85 整一个 K8S 集群，来一个虚拟化专项，打通 CI/CD 流程。

就取一个名字叫研发效能提升专项，而且这个做好了，还能推广到全公司，让公司都用你这套基础设施。

先提高可用性，再说什么一致性之类的事情。

服务可用性是简单最有效提高幸福度的事情了

投资不是一把梭，一定要保证足够的现金等价物。

如果这就是你全部财产的话，毫不犹豫选一。

这些钱就不说什么投资不投资了，所有家庭都应该保留一部分应急资金，存到随时可以拿出来的活期或者 T+1 的稳健理财里。

尤其是你这是期房，万一急用钱你这都变不了现，抵押也没法抵押。

@wgbx 淘宝的收入和成交量并不是正相关。从理论上来说，淘宝最看重的是营收，其次是 GMV 。

所有的个性化推荐都是一套闭环算法，简单的说通过调整推荐算法来进行评估，如果主要评估指标上升，就是一个正反馈，下降就是一个负反馈。

所以说算法本身没有对错，关键是评估指标的设定，算法只会努力提升这个指标。

举个例子，评估指标是广告点击收入，那么算法就会推更恶俗点击率高的广告或者医疗等单价高的广告；再比如评估指标是用户时长，那么算法就会尽量推你会沉迷的短视频，让你多看。

淘宝的评估指标大概率是淘宝的直通车等收入 + 搜索成交率，前者的权重可能还更高一些，也就是他为了收入，可以降低你的搜索成交率，劣化你的搜索体验。

@applehater 北京有身份证就行。

正式牌照需要本人现场或者远程视频的方式验身。

keychain 很好用啊，如果不出现密码提示框，可以自己手动搜

销售专心买车，而不是想办法从你身上赚提成

前段时间买了 Model3，说几个和传统 4S 店不同的购买流程。

1 手机上下单，第二天提车
2 提车当天有事没法去，直接闪送身份证给他们，他们代上临牌，拖车直接运到家门口，免费。我家可离交付中心有 80km
3 不捆绑保险，你可以自己选择上任意公司的保险
4 没有上牌费，特斯拉找一个专门的中介带你上牌，但是费用特斯拉出。
5 没有捆绑销售，也没有强行推销分期等。

另外一个良好的系统设计尽量规避这种并发挂载模式，扩容高可用都不好做。能不用就不用，不过这个看需求，没那么高可用性也不必操心这个。

比如你设计跨越数个机房的高可用系统，光实例就好几万，你再让他们去通过共享存储去共享数据，那显然是一个非常差的选择。

@v2byy 没啥坑，需要底层存储支持。

写时注意别并发冲突了就行。

上面说的影子设备、Future 实例等，都是声明式接口的一种变种。

一般这种非立刻生效但是耗时预估也不会太久（<10s ）的接口，有三种实现模式

同步接口：优点是上层业务逻辑简单，缺点调用耗时较长，接口并发性能较差。
而且偶尔超时后就比较麻烦，有可能状态不一致。比如下发的动作执行了，但是返回时超时。


异步接口：优点是实现简单，还可以利用消息队列等方式来提升性能，理论上接口不会成为性能瓶颈。缺点是上层的业务开发比较复杂，需要自己实现轮询状态或者用长链接监听状态。


声明式接口：上层只需要下发期望，比如下发灯亮这个期望，设备定时去往这个期望变化。这种就类似于 Kubernetes 的接口，优点是能够保证最终一致性，缺点是还需要配合查询接口来轮询或者长链接 Poll 的方式看下当前状态是否达到期望。


目前从开发习惯上，还是同步或者异步接口比较多，但是复杂控制系统声明式接口有它非常大的优势。

114.114.114.114 DNS 解析失败，不推荐使用公共 DNS