FreeBSD-STABLE 居然是开发用的分支,我一直搞错了好多年...!

news/2025/2/26 7:25:40
 
我一直认为对于FreeBSD的系统来说,发行版的稳定性是:CURRENT < RELEASE < STABLE,所以在灌完系统后立刻 cvsup 到对应
的 STABLE 版本去...


这几天刚好碰到 Pengfei 也在看 FreeBSD 的 cvsup 管理部分,他正在疑惑生产系统上面是用 STABLE 还是用 RELEASE 的好,还几乎
要向 CURRENT 靠拢... 我听了后立刻进行“镇压”,强调说:要以STABLE的名义行事,还“忽悠”他说不要看网络上那些被人转手好几
遍的小报技术文章...。


今天早上到公司,收到 Pengfei 的邮件中又提到此问题,我看到出处是《FreeBSD用户手册》,眉宇之间立刻拧成了一个疙瘩,仔细
再次阅读了“
23.2 FreeBSD-CURRENT 和 FreeBSD-STABLE 的对比”。一看之下,立刻意识到了问题的严重性...!

摘录自《FreeBSD 用户手册》

  如果您有兴趣追随 FreeBSD 的开发过程或为其做点贡献, 尤其是和下一个 “非计划” 的 FreeBSD 发行版有关时, 您应该考虑采用 FreeBSD-STABLE。

  尽管安全更新也会进入 FreeBSD-STABLE 分支,但您并不 必须 使用 FreeBSD-STABLE 来达到这样的目的。 每一个 FreeBSD 的安全公告都会解释如何修复受到影响的发行版中的问题 [1],而因为安全原因而去采用一个开发分支显然可能会同时引入一些不希望的修改。

  尽管我们尽力确保 FreeBSD-STABLE 分支在任何时候都能够正确编译和运行, 但没有人能够担保它在任何时候都总可以。 此外, 尽管代码在进入 FreeBSD-STABLE 之前都是在 FreeBSD-CURRENT 上完成开发, 但使用 FreeBSD-STABLE 的人要比使用 FreeBSD-CURRENT 的更多。 有证据显示, 犄角旮旯里的各种问题有些时候仍然会由于在 FreeBSD-CURRENT 不那么明显 而在 FreeBSD-STABLE 暴露出来。

  基于这些原因, 推荐您盲目地追随 FreeBSD-STABLE, 并且, 在粗略地测试过代码之前不要更新任何生产服务器到 FreeBSD-STABLE 也非常重要。

  如果您没有用于完成这些工作的资源, 我们推荐您使用最新的 FreeBSD 发行版, 并使用发行版提供的二进制更新机制来在发行版之间完成迁移。


带着疑问,去请教一下 delphij ,得到的答复再次让自己寒到死...原来自己犯错好多年...

的确:
    <1> CURRENT & STABLE 都是属于开发的代码分支;
    <2> CURRENT 并不会保证随时都可用,属于最前沿的开发分支;
    <3> 代码进入 STABLE 前都会在 CURRENT 分支上面开发完成;
    <4> 生产环境(Production Environment)推荐使用 RELEASE 的发行版;

不要被 STABLE 的字面意思和习惯给迷惑了,英文中的原意如下,看来我们平时翻译的时候多有歧义:

1. not changing: steady and not liable to change, Prices have remained stable.

2. not likely to move: steady or firm and not liable to move

3. not excitable: having a calm and steady temperament, rather than being excitable or given to apparently irrational behavior

4. chemistry physics not readily undergoing change: not subject to changes in chemical or physical properties

5. physics not naturally radioactive: incapable of becoming a different isotope or element by radioactive decay

说了这么多,我还是跑小黑屋反省去了... 感谢一下 Pengfei,俺要学习他的治学精神...





http://www.niftyadmin.cn/n/3653110.html

相关文章

值得读两遍的图书

值得读两遍的一些纯技术类图书&#xff1a;《设计模式》《重构》《J2EE without EJB中文版》 《Ajax实战》《Ajax模式与最佳实践》《Ajax设计模式》值得读两遍的一些非纯技术类图书&#xff1a;《人月神话》《人件》《UML精粹》《编写有效用例》《解析极限编程——拥抱变化》《…

建立国内Web前端开发的生态系统

在2003年年初&#xff0c;因为朋友许恩良的缘故&#xff0c;我来到了上海和为科技有限公司工作。公司的创始人是赖毅&#xff0c;他也曾经是开发人员出身&#xff0c;有着非常丰富的开发经验。赖毅是一个喜欢自出机杼的人&#xff08;这样的人一般都是某一方面的高手&#xff0…

做事情的快与坚持

其实我是一个很急躁的人&#xff0c;总是希望把事情尽快做完。每次出门办事的时候都在想如何把几件事情放在一起来做。但是很多时候&#xff0c;碰到一些疑难问题&#xff0c;总是没有办法快速完成。我总是感觉别人比我做事情要快&#xff0c;所以总是有着一种严重的危机感。读…

Redis 命令参考手册

Redis 命令参考手册 好资料&#xff1a; http://redis.readthedocs.org/en/latest/

linux无锁化编程--__sync_fetch_and_add系列原子操作函数

linux支持的哪些操作是具有原子特性的&#xff1f;知道这些东西是理解和设计无锁化编程算法的基础。 下面的东西整理自网络。先感谢大家的分享&#xff01; __sync_fetch_and_add系列的命令&#xff0c;发现这个系列命令讲的最好的一篇文章&#xff0c;英文好的同学可以直接去…

开始翻译Fielding的博士论文

Fielding是HTTP1.1和URI标准的主要制定者 。他在2000年写了一篇博士论文&#xff0c;提出了REST的架构风格和设计思想。http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm今天REST被众多RIA技术广泛采用&#xff0c;作为设计开发RIA应用的最佳的架构风格。我们已经获…

关于CPU编程—无锁编程

Lock-free 算法通常比基于锁的算法要好&#xff1a; 从其定义来看&#xff0c;它们是 wait-free 的&#xff0c;可以确保线程永远不会阻塞。 状态转变是原子性的&#xff0c;以至于在任何点失败都不会恶化数据结构。 因为线程永远不会阻塞&#xff0c;所以当同步的细粒度是单一…

为什么一定要了解一种技术的细节

作为一名好的程序员&#xff0c;重视细节是一个必须要具备的优点。粗枝大叶的人很难成为一名好的程序员&#xff0c;至于好的架构师就更不要指望了。好的架构师来自于好的程序员&#xff0c;认为自己可以不经过多年程序员的严格考验就成为一名合格的架构师&#xff0c;那是癞蛤…