mirror of
https://github.com/LCTT/TranslateProject.git
synced 2026-08-23 04:03:29 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
121
published/20180930 A Short History of Chaosnet.md
Normal file
121
published/20180930 A Short History of Chaosnet.md
Normal file
@@ -0,0 +1,121 @@
|
||||
Chaosnet 简史
|
||||
===
|
||||
|
||||
如果你输入 `dig` 命令对 `google.com` 进行 DNS 查询，你会得到如下答复：
|
||||
|
||||
```
|
||||
$ dig google.com
|
||||
|
||||
; <<>> DiG 9.10.6 <<>> google.com
|
||||
;; global options: +cmd
|
||||
;; Got answer:
|
||||
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27120
|
||||
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
|
||||
|
||||
;; OPT PSEUDOSECTION:
|
||||
; EDNS: version: 0, flags:; udp: 512
|
||||
;; QUESTION SECTION:
|
||||
;google.com. IN A
|
||||
|
||||
;; ANSWER SECTION:
|
||||
google.com. 194 IN A 216.58.192.206
|
||||
|
||||
;; Query time: 23 msec
|
||||
;; SERVER: 8.8.8.8#53(8.8.8.8)
|
||||
;; WHEN: Fri Sep 21 16:14:48 CDT 2018
|
||||
;; MSG SIZE rcvd: 55
|
||||
```
|
||||
|
||||
这个输出一部分描述了你的问题（`google.com` 的 IP 地址是什么？），另一部分则详细描述了你收到的回答。在<ruby>答案区段<rt>ANSWER SECTION</rt></ruby>里，`dig` 为我们找到了一个包含五个字段的记录。从左数第四个字段 `A` 定义了这个记录的类型 —— 这是一个地址记录。在 `A` 的右边，第五个字段告知我们 `google.com` 的 IP 地址是 `216.58.192.206`。第二个字段，`194` 则代表这个记录的缓存时间是 194 秒。
|
||||
|
||||
那么，`IN` 字段告诉了我们什么呢？令人尴尬的是，在很长的一段时间里，我都认为这是一个介词。那时候我认为 DNS 记录大概是表达了“在 `A` 记录里，`google.com` 的 IP 地址是 `216.58.192.206`。”后来我才知道 `IN` 是 “internet” 的简写。`IN` 这一个部分告诉了我们这个记录分属的<ruby>类别<rt>class</rt></ruby>。
|
||||
|
||||
那么，除了 “internet” 之外，DNS 记录还会有什么别的类别吗？这究竟意味着什么？你怎么去搜寻一个*不位于* internet 上的地址？看起来 `IN` 是唯一一个可能有意义的值。而且的确，如果你尝试去获得除了 `IN` 之外的，关于 `google.com` 的记录的话，DNS 服务器通常不能给出恰当的回应。以下就是我们尝试向 `8.8.8.8`（谷歌公共 DNS 服务器）询问在 `HS` 类别里 `google.com` 的 IP 地址。我们得到了状态为 `SERVFAIL` 的回复。
|
||||
|
||||
```
|
||||
$ dig -c HS google.com
|
||||
|
||||
; <<>> DiG 9.10.6 <<>> -c HS google.com
|
||||
;; global options: +cmd
|
||||
;; Got answer:
|
||||
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31517
|
||||
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
|
||||
|
||||
;; OPT PSEUDOSECTION:
|
||||
; EDNS: version: 0, flags:; udp: 512
|
||||
;; QUESTION SECTION:
|
||||
;google.com. HS A
|
||||
|
||||
;; Query time: 34 msec
|
||||
;; SERVER: 8.8.8.8#53(8.8.8.8)
|
||||
;; WHEN: Tue Sep 25 14:48:10 CDT 2018
|
||||
;; MSG SIZE rcvd: 39
|
||||
```
|
||||
|
||||
所以说，除了 `IN` 以外的类别没有得到广泛支持，但它们的确是存在的。除了 `IN` 之外，DNS 记录还有 `HS`（我们刚刚看到的）和 `CH` 这两个类别。`HS` 类是为一个叫做 [Hesiod][1] 的系统预留的，它可以利用 DNS 来存储并让用户访问一些文本资料。它通常在本地环境中作为 [LDAP][2] 的替代品使用。而 `CH` 这个类别，则是为 Chaosnet 预留的。
|
||||
|
||||
如今，大家都在使用 TCP/IP 协议族。这两种协议（TCP 及 UDP）是绝大部分电脑远程连接采用的协议。不过我觉得，从互联网的垃圾堆里翻出了一个布满灰尘，绝迹已久，被人们遗忘的系统，也是一件令人愉悦的事情。那么，Chaosnet 是什么？为什么它像恐龙一样，走上了毁灭的道路呢？
|
||||
|
||||
### 在 MIT 的机房里
|
||||
|
||||
Chaosnet 是在 1970 年代，由 MIT 人工智能实验室的研究员们研发的。它是一个宏伟目标的一部分 —— 设计并制造一个能比其他通用电脑更高效率运行 Lisp 代码的机器。
|
||||
|
||||
Lisp 是 MIT 教授 John McCarthy 的造物，他亦是人工智能领域的先驱者。在 1960 年发布的[一篇论文][3]中，他首次描述了 Lisp 这个语言。在 1962 年，Lisp 的编译器和解释器诞生了。Lisp 引入了非常多的新特性，这些特性在现在看来是每一门编程语言不可或缺的一部分。它是第一门拥有垃圾回收器的语言，是第一个有 REPL（Read-eval-print-loop：交互式解析器）的语言，也是第一个支持动态类型的语言。在人工智能领域工作的程序员们都十分喜爱这门语言，比如说，大名鼎鼎的 [SHRDLU][4] 就是用它写的。这个程序允许人们使用自然语言，向机器下达挪动玩具方块这样的命令。
|
||||
|
||||
Lisp 的缺点是它太慢了。跟其它语言相比，Lisp 需要使用两倍的时间来执行相同的操作。因为 Lisp 在运行中仍会检查变量类型，而不仅是编译过程中。在 MIT 的 IBM 7090 上，它的垃圾回收器也需要长达一秒钟的时间来执行。[^1] 这个性能问题急需解决，因为 AI 研究者们试图搭建类似 SHRDLU 的应用。他们需要程序与使用者进行实时互动。因此，在 1970 年代的晚期，MIT 人工智能实验室的研究员们决定去建造一个能更高效运行 Lisp 的机器来解决这个问题。这些“Lisp 机器”们拥有更大的存储和更精简的指令集，更加适合 Lisp。类型检查由专门的电路完成，因此在 Lisp 运行速度的提升上达成了质的飞跃。跟那时流行的计算机系统不同，这些机器并不支持分时，整台电脑的资源都用来运行一个单独的 Lisp 程序。每一个用户都会得到他自己单独的 CPU。MIT 的 <ruby>Lisp 机器小组<rt>Lisp Machine Group</rt></ruby>在一个备忘录里提到，这些功能是如何让 Lisp 运行变得更简单的：
|
||||
|
||||
> Lisp 机器是个人电脑。这意味着处理器和主内存并不是分时复用的，每个人都能得到单独属于自己的处理器和内存。这个个人运算系统由许多处理器组成，每个处理器都有它们自己的内存和虚拟内存。当一个用户登录时，他就会被分配一个处理器，在他的登录期间这个处理器是独属于他的。当他登出，这个处理器就会重新可用，等待被分配给下一个用户。通过采取这种方法，当前用户就不用和其他用户竞争内存的使用，他经常使用的内存页也能保存在处理器核心里，因此页面换出的情况被显著降低了。这个 Lisp 机器解决了分时 Lisp 机器的一个基本问题。[^2]
|
||||
|
||||
这个 Lisp 机器跟我们认知的现代个人电脑有很大的不同。该小组原本希望今后用户不用直接面对 Lisp 机器，而是面对终端。那些终端会与位于别处的 Lisp 机器进行连接。虽然每个用户都有自己专属的处理器，但那些处理器在工作时会发出很大的噪音，因此它们最好是位于机房，而不是放在本应安静的办公室里。[^3] 这些处理器会通过一个“完全分布式控制”的高速本地网络共享访问一个文件系统和设备，例如打印机。[^4] 这个网络的名字就是 Chaosnet。
|
||||
|
||||
Chaosnet 既是硬件标准也是软件协议。它的硬件标准与以太网类似，事实上 Chaosnet 软件协议是运行在以太网之上的。这个软件协议在网络层和传输层之间交互，它并不像 TCP/IP，而总是控制着本地网络。Lisp 机器小组的一个成员 David Moon 写的另一个备忘录中提到，Chaosnet “目前并不打算为低速链接、高信噪链接、多路径、长距离链接做特别的优化。” [^5] 他们专注于打造一个在小型网络里表现极佳的协议。
|
||||
|
||||
因为 Chaosnet 连接在 Lisp 处理器和文件系统之间，所以速度十分重要。网络延迟会严重拖慢一些像打开文本文档这种简单操作的速度，为了提高速度，Chaosnet 结合了在<ruby><rb>Network Control Program</rb>网络控制程序</ruby>中使用的一些改进方法，随后的 Arpanet 项目中也使用了这些方法。据 Moon 所说，“为了突破诸如在 Arpanet 中发现的速率瓶颈，很有必要采纳新的设计。目前来看，瓶颈在于由多个链接分享控制链接，而且在下一个信息发送之前，我们需要知道本次信息已经送达。” [^6] Chaosnet 协议族的批量 ACK 包跟当今 TCP 的差不多，它减少了 1/3 到一半的需要传输的包的数量。
|
||||
|
||||
因为绝大多数 Lisp 机器使用较短的单线进行连接，所以 Chaosnet 可以使用较为简单的路由算法。Moon 在 Chaosnet 路由方案中写道“预计要适配的网络架构十分简单，很少有多个路径，而且每个节点之间的距离很短。所以我认为没有必要进行复杂的方案设计。” [^7] 因为 Chaosnet 采用的算法十分简单，所以实现它也很容易。与之对比明显，其实现程序据说只有 Arpanet 网络控制程序的一半。[^8]
|
||||
|
||||
Chaosnet 的另一个特性是，它的地址只有 16 位，是 IPv4 地址的一半。所以这也意味着 Chaosnet 只能在局域网里工作。Chaosnet 也不会去使用端口号；当一个进程试图连接另一个机器上的另外一个进程时，需要首先初始化连接，获取一个特定的目标“<ruby>联系名称<rt>contact name</rt></ruby>”。这个联系名称一般是某个特定服务的名字。比方说，一个主机试图使用 `TELNET` 作为联系名称，连接另一个主机。我认为它的工作方式在实践中有点类似于 TCP，因为有些非常著名的服务也会拥有联系名称，比如运行在 80 端口上的 `HTTP` 服务。
|
||||
|
||||
在 1986 年，[RFC 973][5] 通过了将 Chaosnet DNS 类别加入域名解析系统的决议。它替代了一个早先出现的类别 `CSNET`。`CSNET` 是为了支持一个名叫<ruby>计算机科学网络<rt>Computer Science Network</rt></ruby>而被制造出来的协议。我并不知道为什么 Chaosnet 能被域名解析系统另眼相待。很多别的协议族也有资格加入 DNS，但是却被忽略了。比如 DNS 的主要架构师之一 Paul Mockapetris 提到说在他原本的构想里，<ruby>施乐<rt>Xerox</rt></ruby>的网络协议应该被包括在 DNS 里。[^9] 但是它并没有被加入。Chaosnet 被加入的原因大概是因为 Arpanet 项目和互联网的早期工作，有很多都在麻省剑桥的博尔特·贝拉尼克—纽曼公司，他们的雇员和 MIT 大多有紧密的联系。在这一小撮致力于发展计算机网络人中，Chaosnet 这个协议应该较为有名。
|
||||
|
||||
Chaosnet 随着 Lisp 机器的衰落渐渐变得不那么流行。尽管在一小段时间内 Lisp 机器有实际的商业产品 —— Symbolics 和 Lisp Machines Inc 在 80 年代售卖了这些机器。但它们很快被更便宜的微型计算机替代。这些计算机没有特殊制造的回路，但也可以快速运行 Lisp。Chaosnet 被制造出来的目的之一是解决一些 Apernet 协议的原始设计缺陷，但现在 TCP/IP 协议族同样能够解决这些问题了。
|
||||
|
||||
### 壳中幽灵
|
||||
|
||||
非常不幸的是，在互联网中留存的关于 Chaosnet 的资料不多。RFC 675 —— TCP/IP 的初稿于 1974 年发布，而 Chasnet 于 1975 年开始开发。[^10] 但 TCP/IP 最终征服了整个互联网世界，Chaosnet 则被宣布技术性死亡。尽管 Chaosnet 有可能影响了接下来 TCP/IP 的发展，可我并没有找到能够支持这个猜测的证据。
|
||||
|
||||
唯一一个可见的 Chaosnet 残留就是 DNS 的 `CH` 类。这个事实让我着迷。`CH` 类别是那被遗忘的幽魂 —— 在 TCP/IP 广泛部署中存在的一个替代协议 Chaosnet 的最后栖身之地。至少对于我来说，这件事情是十分让人激动。它告诉我关于 Chaosnet 的最后一丝痕迹，仍然藏在我们日常使用的网络基础架构之中。DNS 的 `CH` 类别是有趣的数码考古学遗迹。但它同时也是活生生的标识，提醒着我们互联网并非天生完整成型的，TCP/IP 不是唯一一个能够让计算机们交流的协议。“万维网”也远远不是我们这全球交流系统所能有的，最酷的名字。
|
||||
|
||||
|
||||
[^1]: LISP 1.5 Programmer’s Manual, The Computation Center and Research Laboratory of Electronics, 90, accessed September 30, 2018, http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf
|
||||
[^2]: Lisp Machine Progress Report (Artificial Intelligence Memo 444), MIT Artificial Intelligence Laboratory, August, 1977, 3, accessed September 30, 2018, https://dspace.mit.edu/bitstream/handle/1721.1/5751/AIM-444.pdf.
|
||||
[^3]: Lisp Machine Progress Report (Artificial Intelligence Memo 444), 4.
|
||||
[^4]: 同上
|
||||
[^5]: Chaosnet (Artificial Intelligence Memo 628), MIT Artificial Intelligence Laboratory, June, 1981, 1, accessed September 30, 2018, https://dspace.mit.edu/bitstream/handle/1721.1/6353/AIM-628.pdf.
|
||||
[^6]: 同上
|
||||
[^7]: Chaosnet (Artificial Intelligence Memo 628), 16.
|
||||
[^8]: Chaosnet (Artificial Intelligence Memo 628), 9.
|
||||
[^9]: Paul Mockapetris and Kevin Dunlap, “The Design of the Domain Name System,” Computer Communication Review 18, no. 4 (August 1988): 3, accessed September 30, 2018, http://www.cs.cornell.edu/people/egs/615/mockapetris.pdf.
|
||||
[^10]: Chaosnet (Artificial Intelligence Memo 628), 1.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://twobithistory.org/2018/09/30/chaosnet.html
|
||||
|
||||
作者：[Two-Bit History][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[acyanbird](https://github.com/acyanbird)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://twobithistory.org
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://en.wikipedia.org/wiki/Hesiod_(name_service)
|
||||
[2]: https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
|
||||
[3]: http://www-formal.stanford.edu/jmc/recursive.pdf
|
||||
[4]: https://en.wikipedia.org/wiki/SHRDLU
|
||||
[5]: https://tools.ietf.org/html/rfc973
|
||||
[6]: https://twitter.com/TwoBitHistory
|
||||
[7]: https://twobithistory.org/feed.xml
|
||||
[8]: https://twitter.com/TwoBitHistory/status/1041485204802756608?ref_src=twsrc%5Etfw
|
||||
@@ -1,21 +1,22 @@
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "MZqk"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
[#]: subject: "What does DevOps mean to you?"
|
||||
[#]: via: "https://opensource.com/article/19/1/what-does-devops-mean-you"
|
||||
[#]: author: "Girish Managoli https://opensource.com/users/gammay"
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (MZqk)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10671-1.html)
|
||||
[#]: subject: (What does DevOps mean to you?)
|
||||
[#]: via: (https://opensource.com/article/19/1/what-does-devops-mean-you)
|
||||
[#]: author: (Girish Managoli https://opensource.com/users/gammay)
|
||||
|
||||
DevOps 对你意味着什么？
|
||||
======
|
||||
6 位专家对 DevOps 的实现、实践关键和哲学分解。
|
||||
|
||||
> 6 位专家为你解析 DevOps 及其实现、实践和哲学的关键。
|
||||
|
||||
|
||||
|
||||
如果你问 10 个人关于 DevOps 的问题，你会得到 12 个答案。这是对于 DevOps 意见和期望多样性的结果，更不用说它在实践中的差异。
|
||||
如果你问 10 个人关于 DevOps 的问题，你会得到 12 个答案。这是对于 DevOps 的意见和期望的多样性的结果，更不用说它在实践中的差异。
|
||||
|
||||
为了解读 DevOps 的悖论，我们找到了最了解它的人 - 这个行业的顶尖从业者。这些人熟悉 DevOps，了解技术的来龙去脉，并且已经有了多年 DevOps 实践。他们的观点应该能鼓励、刺激和激发您对 DevOps 的想法。
|
||||
为了解读 DevOps 的悖论，我们找到了最了解它的人 —— 这个行业的顶尖从业者。这些人熟悉 DevOps，了解技术的来龙去脉，并且已经有了多年 DevOps 实践。他们的观点应该能鼓励、刺激和激发你对 DevOps 的想法。
|
||||
|
||||
### DevOps 对你意味着什么？
|
||||
|
||||
@@ -23,101 +24,87 @@ DevOps 对你意味着什么？
|
||||
|
||||
简而言之，专家们说的是关于 DevOps 的原则、实践和工具。
|
||||
|
||||
IBM 数字企业集团 DevOps 商业平台领导者 [Ann Marie Fred][1]，说，“对于我来说，DevOps 是一套实践的原则，旨在使团队在设计，开发，交付和操作软件方面有更好的效率。”
|
||||
IBM 数字企业集团 DevOps 商业平台领导者 [Ann Marie Fred][1]，说，“对于我来说，DevOps 是一套实践和原则，旨在使团队在设计、开发、交付和操作软件方面有更好的效率。”
|
||||
|
||||
根据红帽资深 DevOps 布道者 [Daniel Oh][2]，“ 通常来说，DevOps 促使企业基于当前的 IT 流程和工具之上发展与开发相关的应用程序 、IT 运营和安全协议。”
|
||||
据红帽资深 DevOps 布道者 [Daniel Oh][2]，“通常来说，DevOps 促使企业基于当前的 IT 发展与应用开发、IT 运维和安全协议的流程和工具。”
|
||||
|
||||
Tactec Strategic Solutions 的创始人 [Brent Reed][3]，就持续改进利益相关者进行了会谈。“DevOps 对我来说意味着一种工作方式，包括一种思维方式，允许持续改进运营绩效，逐渐使其成熟为组织提升绩效，从而让利益相关者高兴。”
|
||||
Tactec 战略解决方案的创始人 [Brent Reed][3]，谈及了利益相关者的持续改进，“DevOps 对我来说意味着包括了一种思维方式的工作方式，它允许持续改进运维绩效，进而提升组织绩效，从而让利益相关者受益。”
|
||||
|
||||
许多专家也强调 DevOps 文化。Ann Marie 说，“这也关于持续改进和学习的问题。它涉及的是人和文化，以及工具和技术。”
|
||||
许多专家也强调 DevOps 文化。Ann Marie 说，“这也是持续改进和学习的问题。它涉及的是人和文化，以及工具和技术。”
|
||||
|
||||
美国保监会 (NAIC) 首席架构师兼 DevOps 领导者 [Dan Barker][4]，“DevOps 主要是关于文化…它将几个独立的领域聚集在一起，如精益生产、[合适文化 ][5] 和持续的学习。我认为文化是最关键和最难执行的。”
|
||||
美国保监会 (NAIC) 首席架构师兼 DevOps 领导者 [Dan Barker][4]，“DevOps 主要是关于文化…它将几个独立的领域聚集在一起，如精益生产、[公正文化][5] 和持续的学习。我认为文化是最关键和最难执行的。”
|
||||
|
||||
Atos 的 DevOps 负责人 [Chris Baynham-Hughes][6]，说，“[DevOps] 实践是通过组织内的文化、流程和工具的发展而被采用的。重点是文化变革，DevOps 文化借鉴的关键是协作、试验、快速反馈和持续改进。”
|
||||
|
||||
云架构师 [Geoff Purdy][7]，谈论敏捷和反馈，“缩短和放大反馈回路。我们希望团队在几分钟内而不是几周内获得反馈。”
|
||||
云架构师 [Geoff Purdy][7]，谈及敏捷和反馈，“缩短和放大反馈回路。我们希望团队在几分钟内而不是几周内获得反馈。”
|
||||
|
||||
但在最后，Daniel 通过解释开源和开源文化是如何让他以简单快捷的方式实现目标来强调这点，“在推动 DevOps 中，最重要的事情应该是开源文化而不是具体的工具或复杂的解决方案。”
|
||||
|
||||
### 你认为哪些 DevOps 实践有效？
|
||||
|
||||
“选择一个自动化配置，对我的团队来说非常有效。”
|
||||
|
||||
专家列举的那些最佳实践是普遍存在的，但又各不相同。
|
||||
|
||||
Ann Marie 表示：“一些十分强大灵活的项目管理[实践]，能在职能、独立的小组之间打破壁垒；全自动化持续部署，蓝/绿部署实现零时间停机状态；开发人员设置自己的监控和警告，无缝自我修复，自动化的安全性与合规性。”
|
||||
|
||||
Chris 说，“特别的突破是倾情合作；持续改成；开放的领导；缩短业务时长；从垂直孤岛转向横向，跨功能的产品团队。工作透明化，相互影响，Mobius 循环，缩短反馈回路，自动化（环境上的 CI/CD）。”
|
||||
Chris 说，“特别的突破是倾情合作、持续改进、开放领导、缩短业务距离、从垂直孤岛转向横向/跨功能的产品团队、工作透明化、相互影响、Mobius 循环、缩短反馈回路、自动化（从环境到 CI/CD）。”
|
||||
|
||||
Brent 支持“发展学习文化，包括 TTD[ 测试驱动开发]和 BDD[ 行为驱动开发]捕获事件，并通过持续集成和持续交付从设计、构建和测试到实施在生产环境上一系列事件的自动化。测试采用故障优先的方法，能够自动化集成和交付流程，并在整个生命周期中包含快速反馈。”
|
||||
Brent 支持“发展学习文化，包括 TTD [测试驱动开发] 和 BDD [行为驱动开发]捕获事件，并通过持续集成和持续交付从设计、构建和测试到实施在生产环境上一系列事件的自动化。测试采用故障优先的方法，能够自动化集成和交付流程，并在整个生命周期中包含快速反馈。”
|
||||
|
||||
Geoff 强调自动化配置。“选择一个自动化配置，对我的团队来说非常有效。更具体地说从版本控制代码库中自动配置。”
|
||||
|
||||
Dan uses fun。“ 我们做了很多不同的事情来建立 DevOps 文化。我们举办 ‘Lunch & Learns”’，提供免费的食物来鼓励大家一起学习。我们买书，分组学习。”
|
||||
Dan 则玩的开心，“ 我们做了很多不同的事情来建立 DevOps 文化。我们举办 ‘午餐 & 学习’ 活动，提供免费的食物来鼓励大家一起学习。我们买书，分组学习。”
|
||||
|
||||
### 你如何激励你的团队实现 DevOps 这个目标？
|
||||
|
||||
```
|
||||
"庆祝你所取得的进步。"
|
||||
```
|
||||
Daniel 强调“自动化的问题就是为了减少 DevOps 计划中来自多个团队的异议，你应该鼓励你的团队提高开发、测试与 IT 运营的自动化能力，以及新的流程和程序。例如，Linux 容器是实现 DevOps 自动化功能的关键工具。”
|
||||
|
||||
Daniel 强调“自动化的问题就是为了减少 DevOps 计划中来自多个团队的异议，您应该鼓励您的团队提高开发、测试与 IT 运营的自动化能力，以及新的流程和程序。例如，Linux 容器是实现 DevOps 自动化功能的关键工具。”
|
||||
Geoff 很是赞同，“机械化的劳作，你有讨厌现在做的任务吗？很棒。如果可能的话，让它们消失。不行，那就让它们自动化。它能使工作不会变得太枯燥，因为工作总是在变化。”
|
||||
|
||||
Geoff 很是赞同，“机械化的劳作，你有讨厌现在做的任务吗？很棒。如果可能的话，让它们消失。不行，那就让他们自动化。它能使工作不会变得太枯燥，因为工作总是在变化。”
|
||||
Dan、Ann Marie 和 Brent 强调团队的执行力。
|
||||
|
||||
Dan，Ann Marie 和 Brent 强调团队的执行力。
|
||||
Dan 说，“在 NAIC，我们有个很好的奖励系统来鼓励特定的行为。我们有多个级别的奖项，其中两个奖项可以由任何人颁布给某人。我们也会颁奖给完成重要任务的团队，但我们通常只奖励给个人贡献者。”
|
||||
|
||||
Dan 说，“在 NAIC，我们有个很好的奖励系统来鼓励特定的行为。我们有多个级别的奖项，其中两个奖项可以任何人颁布给某人。我们也会颁奖给完成重要任务的团队，但我们通常只奖励给个人贡献者。”
|
||||
Ann Marie 表示，“我所在地区的团队最大的动力是看见其他人成功。我们每周都会彼此回放一次，其中一部分是分享我们从尝试新工具或实践中学到的东西。团队热衷于他们现在做的事情，并愿意帮助其他人开始，相信更多的团队很快也会加入进来。”
|
||||
|
||||
Ann Marie 表示，“我所在地区的团队最大的动力是看见其他人成功。我们每周都会彼此播放一次，其中一部分是分享我们从尝试新工具或实践中学到的东西。团队热衷于他们现在做的事情，并愿意帮助其他人开始，相信更多的团队很快也会加入进来。”
|
||||
Brent 表示赞同。“让每个人学习，并掌握同样的基础知识至关重要……我喜欢从评估什么能帮助团队实现目标[以及]产品负责人和用户需要提供的内容入手。”
|
||||
|
||||
Brent 表示赞同。“让每个人学习，并掌握基础知识同样至关重要。。。。。。我喜欢从评估什么能帮助团队实现目标[以及]产品负责人和用户需要提供的内容入手。”
|
||||
|
||||
Chris 推荐采用双管齐下的方法。“每周运行可以实现的小目标，并且[在这]可以看到他们正在运做的功能工作之外的进展，庆祝你所取得的进步。”
|
||||
Chris 推荐采用双管齐下的方法。“运行可以每周可以实现的小目标，并且[在这]可以看到他们正在运做的功能工作之外的进展，庆祝你所取得的进步。”
|
||||
|
||||
### DevOps 和敏捷开发如何协同工作？
|
||||
|
||||
|
||||
```
|
||||
“DevOps ！= 敏捷。其次 敏捷 ！=Scrum流程”
|
||||
```
|
||||
|
||||
这是一个重要的问题，因为 DevOps 和敏捷开发都是现代软件开发的基石。
|
||||
|
||||
DevOps 是一个软件开发的过程，专注与沟通与协作，以促进快速部署应用程序和产品。而敏捷开发是一种开发方法，涉及持续开发，连续迭代和连续测试，以实现可预测和可交付的成果质量。
|
||||
DevOps 是一个软件开发的过程，专注与沟通与协作，以促进快速部署应用程序和产品。而敏捷开发是一种开发方法，涉及持续开发、连续迭代和连续测试，以实现可预测和可交付的成果质量。
|
||||
|
||||
那么，它们又有怎样的联系？让我们去问问专家吧。
|
||||
|
||||
在 Brent 来看，“DevOps！= 敏捷。其次 敏捷！=Scrum 流程。。。敏捷工具和工作方式——支撑着 DevOps 策略和目标——它们是如此融合在一起的。”
|
||||
在 Brent 来看，“DevOps != 敏捷。其次 敏捷 != Scrum 流程……敏捷工具和工作方式支撑着 DevOps 策略和目标，它们是如此融合在一起的。”
|
||||
|
||||
Chris 说，“对我而言敏捷是 DevOps 的一个基本组件。当然，我们可以讨论如何在非敏捷开发环境中采用 DevOps 文化，但最终表明，提高软件设计方式的灵活性是采用 DevOps 成熟读的一个关键指标。”
|
||||
|
||||
Dan 将 DevOps 与更伟大的[敏捷宣言 ][8] 联系起来。“我在谈到敏捷时总会引用敏捷宣言来设置基准，而有许多实现中并不关注宣言。当您阅读宣言时，您会发现它确实从开发的角度描述了 DevOps。因此，将敏捷融入 DevOps 文化非常容易，因为敏捷关注于沟通、协作、变化的灵活性以及快速地投入生产。”
|
||||
Dan 将 DevOps 与更伟大的 [敏捷宣言][8] 联系起来。“我在谈到敏捷时总会引用敏捷宣言来设置基准，而有许多实现中并不关注该宣言。当你阅读这份宣言时，你会发现它确实从开发的角度描述了 DevOps。因此，将敏捷融入 DevOps 文化非常容易，因为敏捷关注于沟通、协作、变化的灵活性以及快速地投入生产。”
|
||||
|
||||
Geoff 认为 “DevOps 是敏捷实施的众多实现之一。敏捷本质上是一套原则，而 DevOps 则是体现这些原则的文化、流程和工具链。”
|
||||
|
||||
Ann Marie 简洁说明，“敏捷是 DevOps 的先决条件。DevOps 使敏捷变得更加有效。”
|
||||
|
||||
### DevOps 是否受益于开源？
|
||||
```
|
||||
”开源做得好，需要DevOps文化。“
|
||||
```
|
||||
|
||||
这个问题得到了所有参与者的热烈肯定，然后解释了他们看到的好处。
|
||||
|
||||
Ann Marie 说，”我们站在巨人的肩膀上，在已有的基础之上发展。拉取请求和代码评审的开源模式，对 DevOps 团队维护软件很有效果。“
|
||||
Ann Marie 说，“我们站在巨人的肩膀上，在已有的基础之上发展。拉取请求和代码评审的开源模式，对 DevOps 团队维护软件很有效果。”
|
||||
|
||||
Chris” 毫无疑问“地赞同 DevOps 受益于开源。”从设计和工具方面（例如，Ansible），到流程和人员方面，通分享行业内的故事和开源社区的领导。“
|
||||
Chris 赞同 DevOps “毫无疑问”受益于开源。“从设计和工具方面（例如，Ansible），到流程和人员方面，通分享行业内的故事和开源社区的领导。”
|
||||
|
||||
Geoff 提到一个好处是”基层的采纳“。没有人需要签署购买或申请免费（如免费啤酒）的软件。团队发现了满足他们需求的工具，可以自行（自由的）进行修改。[然后]在它之上构建，并为更大的社区提供更好的功能。如此往复。
|
||||
Geoff 提到一个好处是“基层的采纳”。免费的软件不需要签署购买申请。团队发现了满足他们需求的工具，可以自行进行修改。[然后]在它之上构建，并为更大的社区提供更好的功能。如此往复。
|
||||
|
||||
开源已经向 DevOps 展示着”就像开源软件开发者那样做，采用更好的方式来来克服新的变化 “，Daniel 说。
|
||||
开源已经向 DevOps 展示着“就像开源软件开发者正在做的那样，采用更好的方式来克服新的变化”，Daniel 说。
|
||||
|
||||
Brent 同意道 ”DevOps 从开源中获益良多。一种方法是使用这些工具来理解它们是如何加速 DevOps 的目标和策略；在自动化、自动伸缩、虚拟化和容器化等关键方面对开发人员和操作人员进行培训，如果不引入使 DevOps 更加容易的技术支持，就很难实现这些特性。”
|
||||
Brent 同意道 “DevOps 从开源中获益良多。一种方法是使用这些工具来理解它们是如何加速 DevOps 的目标和策略；在自动化、自动伸缩、虚拟化和容器化等关键方面对开发人员和操作人员进行培训，如果不引入使 DevOps 更加容易的技术支持，就很难实现这些特性。”
|
||||
|
||||
Dan 指出了 DevOps 和开源之间的双向共生关系，“做好开源需要 DevOps 文化。大多数开源项目都具有非常开放的沟通结构，很少有不透明的地方。对于 Devops 实践者来说，这实际上是一个很好的学习机会，可以让他们了解到可能需要将什么引入自己的组织中。此外能够使用来自社区与组织类似的工具来鼓励自己的文化成长。我喜欢用 GitLab 作为这种共生关系的一个例子。当我把 GitLab 带入一家公司时，我们得到了一个很棒的工具，但我们真正购买的是他们独特的文化，通过我们与他们的互动以及我们的贡献带来了巨大价值。他们的工具也可以为 Devops 组织提供更多东西，而他们的文化已经在我介绍它给的公司中引起了他们的敬畏。”
|
||||
Dan 指出了 DevOps 和开源之间的双向共生关系，“做好开源需要 DevOps 文化。大多数开源项目都具有非常开放的沟通结构，很少有不透明的地方。对于 Devops 实践者来说，这实际上是一个很好的学习机会，可以让他们了解到可能需要将什么引入自己的组织中。此外能够使用来自社区与组织类似的工具来鼓励自己的文化成长。我喜欢用 GitLab 作为这种共生关系的一个例子。当我把 GitLab 带入一家公司时，我们得到了一个很棒的工具，但我们真正购买的是他们独特的文化，通过我们与他们的互动以及我们的贡献带来了巨大价值。他们的工具也可以为 DevOps 组织提供更多东西，而他们的文化已经在我引入它的公司中引起了他们的敬畏。”
|
||||
|
||||
现在我们的 DevOps 专家已经参与进来了，请在评论中分享您对 DevOps 的理解，以及向我们提出其其他问题。
|
||||
现在我们的 DevOps 专家已经参与进来了，请在评论中分享你对 DevOps 的理解，以及向我们提出其他问题。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@@ -126,7 +113,7 @@ via: https://opensource.com/article/19/1/what-does-devops-mean-you
|
||||
作者：[Girish Managoli][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[MZqk](https://github.com/MZqk)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-10673-1.html)
|
||||
[#]: subject: (How To Navigate Inside A Directory/Folder In Linux Without CD Command?)
|
||||
[#]: via: (https://www.2daygeek.com/navigate-switch-directory-without-using-cd-command-in-linux/)
|
||||
[#]: author: (Magesh Maruthamuthu https://www.2daygeek.com/author/magesh/)
|
||||
@@ -10,19 +10,17 @@
|
||||
如何在 Linux 中不使用 CD 命令进入目录/文件夹？
|
||||
======
|
||||
|
||||
众所周知，如果没有 CD 命令，我们无法 Linux 中切换目录。
|
||||
|
||||
这个没错，但我们有一个名为 `shopt` 的 Linux 内置命令能帮助我们解决这个问题。
|
||||
众所周知，如果没有 `cd` 命令，我们无法 Linux 中切换目录。这个没错，但我们有一个名为 `shopt` 的 Linux 内置命令能帮助我们解决这个问题。
|
||||
|
||||
[shopt][1] 是一个 shell 内置命令，用于设置和取消设置各种 bash shell 选项，由于它已安装，因此我们不需要再次安装它。
|
||||
|
||||
是的，我们可以在启用此选项后，可以不使用 CD 命令切换目录。
|
||||
是的，我们可以在启用此选项后，可以不使用 `cd` 命令切换目录。
|
||||
|
||||
我们将在本文中向你展示如何操作。这是一个小的调整，但对于那些从 Windows 迁移到 Linux 的新手来说非常有用。
|
||||
|
||||
这对 Linux 管理员没用，因为我们不会在没有 CD 命令的情况下切换到该目录，因为我们对此有一个很好的做法。
|
||||
这对 Linux 管理员没用，因为我们不会在没有 `cd` 命令的情况下切换到该目录，因为我们对此有经验。
|
||||
|
||||
如果你尝试在没有 cd 命令的情况下切换 Linux 的目录/文件夹，你将看到以下错误消息。这在 Linux 中很常见。
|
||||
如果你尝试在没有 `cd` 命令的情况下切换 Linux 的目录/文件夹，你将看到以下错误消息。这在 Linux 中很常见。
|
||||
|
||||
```
|
||||
$ Documents/
|
||||
@@ -33,15 +31,19 @@ bash: Documents/: Is a directory
|
||||
|
||||
### 什么是 .bashrc ？
|
||||
|
||||
“.bashrc” 是一个 shell 脚本，每次用户以交互模式打开新 shell 时都会运行该脚本。
|
||||
`.bashrc` 是一个 shell 脚本，每次用户以交互模式打开新 shell 时都会运行该脚本。
|
||||
|
||||
你可以在该文件中添加要在命令提示符下输入的任何命令。
|
||||
|
||||
.bashrc 文件本身包含终端会话的一系列配置。包括设置和启用：着色、补全，shell 历史，命令别名等。
|
||||
`.bashrc` 文件本身包含终端会话的一系列配置。包括设置和启用：着色、补全，shell 历史，命令别名等。
|
||||
|
||||
```
|
||||
$ vi ~/.bashrc
|
||||
```
|
||||
|
||||
加入这一行：
|
||||
|
||||
```
|
||||
shopt -s autocd
|
||||
```
|
||||
|
||||
@@ -68,12 +70,14 @@ $ pwd
|
||||
```
|
||||
|
||||
![][3]
|
||||
|
||||
是的，它正如预期的那样正常工作。
|
||||
|
||||
而且，它在 `fish shell` 中工作正常，而无需对 `.bashrc` 进行任何更改。
|
||||
而且，它在 fish shell 中工作正常，而无需对 `.bashrc` 进行任何更改。
|
||||
|
||||
![][4]
|
||||
|
||||
如果要暂时执行此操作，请使用以下命令（set/unset）。重启系统时，它将消失。
|
||||
如果要暂时执行此操作，请使用以下命令（`set`/`unset`）。重启系统时，它将消失。
|
||||
|
||||
```
|
||||
# shopt -s autocd
|
||||
@@ -87,7 +91,7 @@ autocd on
|
||||
autocd off
|
||||
```
|
||||
|
||||
shopt 命令提供了许多其他选项，如果要验证这些选项，请运行以下命令。
|
||||
`shopt` 命令提供了许多其他选项，如果要验证这些选项，请运行以下命令。
|
||||
|
||||
```
|
||||
$ shopt
|
||||
@@ -146,9 +150,9 @@ sourcepath on
|
||||
xpg_echo off
|
||||
```
|
||||
|
||||
我找到了一些其他程序，它们可以帮助我们在 Linux 中比 cd 命令更快地切换目录。
|
||||
此外，我找到了一些其他程序，它们可以帮助我们在 Linux 中比 `cd` 命令更快地切换目录。
|
||||
|
||||
它们是 pushd、popd、up shell 脚本和 bd 工具。我们将在接下来的文章中介绍这些主题。
|
||||
它们是 `pushd`、`popd`、`up` shell 脚本和 `bd` 工具。我们将在接下来的文章中介绍这些主题。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@@ -157,7 +161,7 @@ via: https://www.2daygeek.com/navigate-switch-directory-without-using-cd-command
|
||||
作者：[Magesh Maruthamuthu][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@@ -1,117 +0,0 @@
|
||||
Chaosnet 简史
|
||||
===
|
||||
|
||||
如果你输入 `dig` 命令对 `google.com` 进行 DNS 查询，你会得到如下答复：
|
||||
|
||||
```
|
||||
$ dig google.com
|
||||
|
||||
; <<>> DiG 9.10.6 <<>> google.com
|
||||
;; global options: +cmd
|
||||
;; Got answer:
|
||||
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27120
|
||||
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
|
||||
|
||||
;; OPT PSEUDOSECTION:
|
||||
; EDNS: version: 0, flags:; udp: 512
|
||||
;; QUESTION SECTION:
|
||||
;google.com. IN A
|
||||
|
||||
;; ANSWER SECTION:
|
||||
google.com. 194 IN A 216.58.192.206
|
||||
|
||||
;; Query time: 23 msec
|
||||
;; SERVER: 8.8.8.8#53(8.8.8.8)
|
||||
;; WHEN: Fri Sep 21 16:14:48 CDT 2018
|
||||
;; MSG SIZE rcvd: 55
|
||||
```
|
||||
|
||||
这个输出一部分描述了你的问题（“ `google.com` 的 IP 地址是什么？），另一部分则详细解析了你收到的回答。在<ruby>答案区段<rb>ANSWER SECTION</rb></ruby>里，`dig` 为我们创造了一个包含五个字段的记录。从左数第四个字段 `A` 定义了这个记录的类型 —— 这是一个地址记录。在 `A` 的右边，第五个字段告知我们 `google.com` 的 `IP` 地址是 `216.58.192.206`。第二个字段，`194` 则代表这个记录的缓存时间是 194 秒。
|
||||
|
||||
那么， `IN` 字段告诉了我们什么呢？令人尴尬的是，在很长的一段时间里，我都认为这是一个介词。那时候我认为 DNS 记录大概是表达了“在 `A` 记录里，`google.com` 的 `IP` 地址是 `216.58.192.206`。”后来我才知道 `IN` 是“internet”的简写。`IN` 这一个部分告诉了我们这个记录分属的类别。
|
||||
|
||||
那么，除了“internet”之外，DNS 记录还会有什么别的类别吗？这究竟意味着什么？你怎么去搜寻一个不位于 internet 上的地址？看起来 `IN` 是唯一一个可能填写进这个字段的答案。而且的确，如果你尝试去获得除了 `IN` 之外的，关于 `google.com` 的记录的话，DNS 服务器通常不能给出恰当的回应。但凡事总有意外，以下就是我们尝试向 `8.8.8.8`（谷歌公共 DNS 服务器）询问在 `HS` 类别里 `google.com` 的 IP 地址。我们得到了状态为 `SERVFAIL` 的回复。
|
||||
|
||||
```
|
||||
$ dig -c HS google.com
|
||||
|
||||
; <<>> DiG 9.10.6 <<>> -c HS google.com
|
||||
;; global options: +cmd
|
||||
;; Got answer:
|
||||
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31517
|
||||
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
|
||||
|
||||
;; OPT PSEUDOSECTION:
|
||||
; EDNS: version: 0, flags:; udp: 512
|
||||
;; QUESTION SECTION:
|
||||
;google.com. HS A
|
||||
|
||||
;; Query time: 34 msec
|
||||
;; SERVER: 8.8.8.8#53(8.8.8.8)
|
||||
;; WHEN: Tue Sep 25 14:48:10 CDT 2018
|
||||
;; MSG SIZE rcvd: 39
|
||||
```
|
||||
|
||||
所以说，除了 `IN` 以外的类别不能被服务器广泛支持，但它们的确是存在的。除了 `IN` 之外，DNS 记录还有 `HS`（我们刚刚看到的）和 `CH` 这两个类别。`HS` 类是为一个叫做 [Hesiod][1] 的系统预留的，它可以利用 DNS 来存储并让用户访问一些文本资料。它通常在本地环境中作为 [LDAP][2] 的替代品使用。而 `CH` 这个类别，则是为 Chaosnet 技术预留的。
|
||||
|
||||
如今，大家都在使用 TCP/IP 协议族。这两种协议（还有 UDP）是绝大部分电脑远程连接采用的协议。不过我觉得，从互联网的垃圾堆里翻出了一个布满灰尘，绝迹已久，被人们遗忘的系统，也是一件令人愉悦的事情。那么，Chaosnet 是什么？为什么它像恐龙一样，走上了毁灭的道路呢？
|
||||
|
||||
### 在 MIT 的机房里
|
||||
|
||||
Chaosnet 是在 1970 年代，由 MIT 人工智能实验室的研究员们研发的。它是一个宏伟目标的一部分 —— 设计并制造一个能比其他电脑更高效率运行 Lisp 代码的机器。
|
||||
|
||||
Lisp 是 MIT 教授 John McCarthy 的造物，他亦是人工智能领域的先驱者。在 1960 年发布的[一篇论文][3]中，他首次描述了 Lisp 这个语言。在 1962 年，Lisp 的编译器和解释器诞生了。Lisp 拥有非常多的新特性。这些特性在现在看来是每一门编程语言不可或缺的一部分。它是第一门拥有垃圾回收器，REPL 和支持的动态类型的语言。在人工智能领域工作的程序员们都十分喜爱这门语言，比如说 —— 大名鼎鼎的 [SHRDLU][4] 就是用它写的。这个程序允许人们使用自然语言，向机器下达挪动玩具方块这样的命令。
|
||||
|
||||
Lisp 的缺点是它太慢了。跟其他语言相比，Lisp 需要使用两倍的时间来执行相同的操作。因为 Lisp 在运行中仍会检查变量类型，这一操作通常都是在编译过程中完成的。在 IBM 7090 上，它的垃圾回收器也需要长达一秒钟的时间来执行。这个问题急需解决，因为 AI 研究者们试图搭建类似 SHRDLU 的应用。他们需要程序与使用者进行实时互动。因此，在 1970 年代的晚期，MIT 人工智能研究所的研究员们决定去建造一个能更高效运行 Lisp 的机器来解决这个问题。这些“Lisp 机器”们拥有更大的存储和更小的指令集，更加适合 Lisp。类型检查由专门的回路完成，因此在 Lisp 运行速度的提升上达成了质的飞跃。跟那时流行的计算机系统不同，这些机器并不支持分时，整台电脑的资源都用来运行一个单独的 Lisp 程序。每一个用户都会得到单独的 CPU。Lisp 机器研发小组在一个备忘录里提到，这些功能是如何让 Lisp 运行变得更简单的：
|
||||
|
||||
>Lisp 机器是个人电脑。它支持个人编程，这意味着处理器和内存并不是分时多工的，每个人都能得到单属于自己的处理器和内存。这个私人运算系统由许多处理器组成，每个处理器都有它们自己的内存和虚拟内存。当一个用户登陆时，他就会被分配一个处理器，在他的登陆期间这个处理器是独属于他的。当他登出，这个处理器就会重新可用，等待被分配给下一个用户。通过采取这种方法，当前用户就不用和其他用户竞争内存的使用，他经常使用的信息也能保存在核心里，因此把信息调出所需要的时间也大大缩短了。这个 Lisp 机器解决了分时 Lisp 机器里产生的问题。
|
||||
|
||||
这个 Lisp 机器跟我们认知的现代个人电脑由很大的不同。开发小组希望今后用户不用直接面对 Lisp 机器，而是面对终端。那些终端会与位于别处的 Lisp 机器进行连接。虽然每个用户都有自己专属的处理器，但那些处理器在工作时会发出很大的噪音，因此它们最好是位于机房，而不是放在本应安静的办公室里。这些处理器会共享一个文件系统，然后通过一个“完全分布式控制”的高速本地网络访问设备，例如打印机。这个网络的名字就是 Chaosnet。
|
||||
|
||||
Chaosnet 既是硬件标准也是软件的协议。它的硬件标准与以太网类似，事实上软件协议也是运行在以太网之上的。这个软件协议在网络层和传输层之间交互，它并不像 TCP/IP，一直控制着本地网络。Lisp 机器开发小组的一个成员， David Moon 写的备忘录中提到，Chaosnet “目前并不打算为低速链接，噪链，多路径，长距离链接做特别的优化。”他们专注于打造一个在小型网络里表现极佳的协议。
|
||||
|
||||
因为 Chaosnet 连接在 Lisp 处理器和文件系统之间，所以速度十分重要。网络延迟会严重拖慢一些像打开文本文档这种简单操作的速度，为了提高速度，Chaosnet 结合了在<ruby><rb>Network Control Program</rb>网络控制程序</ruby>中使用的一些改进方法，随后的 Arpanet 项目中也使用了这些方法。根据 Moon 说过的“为了突破速率瓶颈，很有必要采纳新的设计。目前来看，瓶颈在于由多个链接分享控制链接，而且在下一个信息发送之前，我们需要知道本次信息已经送达。”Chaosnet 协议簇的 ACK 包跟当今 TCP 的差不多，它减少了 1/3 到一半的需要传输的包的数量。
|
||||
|
||||
因为绝大多数 Lisp 机器使用较短的单线进行连接，所以 Chaosnet 可以使用较为简单的路径算法。Moon 在 Chaosnet 路径的发展规划中写道“预计要适配的网络架构十分简单，并没有包含多少路径，而且每个节点之间的距离很短。所以我认为没有必要进行复杂的方案设计。”因为 Chaosnet 采用的算法十分简单，所以部署它也很容易。与之对比明显，Arpanet 网络控制项目的内容一半与部署有关。
|
||||
|
||||
Chaosnet 的另一个特性是，它的地址只有 16 bit，是 IPv4 地址的一半。所以这也意味着 Chaosnet 只能在局域网里工作。Chaosnet 也不会去使用端口号；当一个进程试图连接另一个机器上的其他进程时，需要首先初始化连接，获取一个特定的“连接名称”。这个连接名称一般是某个特定服务的名字。比方说，一个主机试图使用 `TELNET` 作为连接名称，连接另一个主机。我认为它的工作方式在实践中类似于 TCP，因为有些非常著名的服务也会拥有连接名称，比如运行在 80 端口上的 `HTTP` 服务。
|
||||
|
||||
在 1986 年，[RFC 973][5] 通过了将 Chaosnet DNS 类别加入域名解析系统的决议。它替代了一个早先出现的类别`CSNET` 。`CSNET` 是为了支持一个名叫计算机科学网络而被制造出来的协议。我并不知道为什么 Chaosnet 能被域名解析系统另眼相待。很多别的协议也有资格加入 DNS，但是却被忽略了。比如说 Xerox’s 网络协议，在域名解析系统的创办人之一 Paul Mockapetris 提到，在他原本的构想里这个协议应该被包括在 DNS 里。但是它并没有被加入。Chaosnet 被加入的原因大概是因为 Arpanet 项目的早期工作，有很多都在剑桥的 Bolt， Beranek 和 Newman 学院。因此研究人员和 MIT 大多有紧密的联系。在这一小撮致力于发展计算机网络人中，Chaosnet 这个协议应该较为有名。
|
||||
|
||||
Chaosnet 随着 Lisp 机器的衰落渐渐变得不那么流行。尽管在一小段时间内 Lisp 机器有商业应用 —— Symbolics 和 Lisp Machines Inc 在 80 年代售卖了这些机器。但它们很快被更便宜的微型计算机替代。这些计算机没有特殊制造的回路，但也可以快速运行 Lisp。Chaosnet 被制造出来的目的之一是解决一些 Apernet 协议的原始设计缺陷，但现在 TCP/IP 协议族同样能够解决这些问题了。
|
||||
|
||||
### 壳中幽灵
|
||||
|
||||
非常不幸的是，在互联网中留存的关于 Chaosnet 的资料不多。RFC 675 —— TCP/IP 的初稿于 1974 年发布，而Chasnet 于 1975 年开始开发。但 TCP/IP 最终征服了整个互联网世界，Chaosnet 则被宣布技术性死亡。尽管 Chaosnet 有可能影响了接下来 TCP/IP 的发展，可我并没有找到能够支持这个猜测的证据。
|
||||
|
||||
唯一一个可见的 Chaosnet 残留就是 DNS 的 `CH` 类。这个事实让我着迷。`CH` 类别是那被遗忘的幽魂 —— 在 TCP/IP 广泛部署存在的，Chaosnet 协议的最后栖身之地。至少对于我来说，这件事情是十分让人激动。它告诉我关于 Chaosnet 的最后一丝痕迹，仍然藏在我们日常使用的网络基础架构之中。DNS 的 `CH` 类别是有趣的数码考古学遗迹。但它同时也是活生生的标识，提醒着我们互联网尚未完全诞生，TCP/IP 不是唯一一个能够让计算机们交流的协议。“万维网”也远远不是我们这全球交流系统所能有的，最酷的名字。
|
||||
|
||||
如果你喜欢这篇文章，欢迎订阅 [RSS feed][7] 来查看最新更新。
|
||||
|
||||
过往文章
|
||||
|
||||
> RSS 是如何诞生的？ 它当时为何盛极一时，但现在鲜为人知？
|
||||
>
|
||||
> — TwoBitHistory (@TwoBitHistory) [September 17, 2018][8]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://twobithistory.org/2018/09/30/chaosnet.html
|
||||
|
||||
作者：[Two-Bit History][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[acyanbird](https://github.com/acyanbird)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://twobithistory.org
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://en.wikipedia.org/wiki/Hesiod_(name_service)
|
||||
[2]: https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
|
||||
[3]: http://www-formal.stanford.edu/jmc/recursive.pdf
|
||||
[4]: https://en.wikipedia.org/wiki/SHRDLU
|
||||
[5]: https://tools.ietf.org/html/rfc973
|
||||
[6]: https://twitter.com/TwoBitHistory
|
||||
[7]: https://twobithistory.org/feed.xml
|
||||
[8]: https://twitter.com/TwoBitHistory/status/1041485204802756608?ref_src=twsrc%5Etfw
|
||||
Reference in New Issue
Block a user