分类 观点 下的文章

如果你输入 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 地址是什么?),另一部分则详细描述了你收到的回答。在 答案区段 ANSWER SECTION 里,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 这一个部分告诉了我们这个记录分属的 类别 class

那么,除了 “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) 的系统预留的,它可以利用 DNS 来存储并让用户访问一些文本资料。它通常在本地环境中作为 LDAP 的替代品使用。而 CH 这个类别,则是为 Chaosnet 预留的。

如今,大家都在使用 TCP/IP 协议族。这两种协议(TCP 及 UDP)是绝大部分电脑远程连接采用的协议。不过我觉得,从互联网的垃圾堆里翻出了一个布满灰尘,绝迹已久,被人们遗忘的系统,也是一件令人愉悦的事情。那么,Chaosnet 是什么?为什么它像恐龙一样,走上了毁灭的道路呢?

在 MIT 的机房里

Chaosnet 是在 1970 年代,由 MIT 人工智能实验室的研究员们研发的。它是一个宏伟目标的一部分 —— 设计并制造一个能比其他通用电脑更高效率运行 Lisp 代码的机器。

Lisp 是 MIT 教授 John McCarthy 的造物,他亦是人工智能领域的先驱者。在 1960 年发布的一篇论文中,他首次描述了 Lisp 这个语言。在 1962 年,Lisp 的编译器和解释器诞生了。Lisp 引入了非常多的新特性,这些特性在现在看来是每一门编程语言不可或缺的一部分。它是第一门拥有垃圾回收器的语言,是第一个有 REPL(Read-eval-print-loop:交互式解析器)的语言,也是第一个支持动态类型的语言。在人工智能领域工作的程序员们都十分喜爱这门语言,比如说,大名鼎鼎的 SHRDLU 就是用它写的。这个程序允许人们使用自然语言,向机器下达挪动玩具方块这样的命令。

Lisp 的缺点是它太慢了。跟其它语言相比,Lisp 需要使用两倍的时间来执行相同的操作。因为 Lisp 在运行中仍会检查变量类型,而不仅是编译过程中。在 MIT 的 IBM 7090 上,它的垃圾回收器也需要长达一秒钟的时间来执行。 1 这个性能问题急需解决,因为 AI 研究者们试图搭建类似 SHRDLU 的应用。他们需要程序与使用者进行实时互动。因此,在 1970 年代的晚期,MIT 人工智能实验室的研究员们决定去建造一个能更高效运行 Lisp 的机器来解决这个问题。这些“Lisp 机器”们拥有更大的存储和更精简的指令集,更加适合 Lisp。类型检查由专门的电路完成,因此在 Lisp 运行速度的提升上达成了质的飞跃。跟那时流行的计算机系统不同,这些机器并不支持分时,整台电脑的资源都用来运行一个单独的 Lisp 程序。每一个用户都会得到他自己单独的 CPU。MIT 的 Lisp 机器小组 Lisp Machine Group 在一个备忘录里提到,这些功能是如何让 Lisp 运行变得更简单的:

Lisp 机器是个人电脑。这意味着处理器和主内存并不是分时复用的,每个人都能得到单独属于自己的处理器和内存。这个个人运算系统由许多处理器组成,每个处理器都有它们自己的内存和虚拟内存。当一个用户登录时,他就会被分配一个处理器,在他的登录期间这个处理器是独属于他的。当他登出,这个处理器就会重新可用,等待被分配给下一个用户。通过采取这种方法,当前用户就不用和其他用户竞争内存的使用,他经常使用的内存页也能保存在处理器核心里,因此页面换出的情况被显著降低了。这个 Lisp 机器解决了分时 Lisp 机器的一个基本问题。 2

这个 Lisp 机器跟我们认知的现代个人电脑有很大的不同。该小组原本希望今后用户不用直接面对 Lisp 机器,而是面对终端。那些终端会与位于别处的 Lisp 机器进行连接。虽然每个用户都有自己专属的处理器,但那些处理器在工作时会发出很大的噪音,因此它们最好是位于机房,而不是放在本应安静的办公室里。 3 这些处理器会通过一个“完全分布式控制”的高速本地网络共享访问一个文件系统和设备,例如打印机。 4 这个网络的名字就是 Chaosnet。

Chaosnet 既是硬件标准也是软件协议。它的硬件标准与以太网类似,事实上 Chaosnet 软件协议是运行在以太网之上的。这个软件协议在网络层和传输层之间交互,它并不像 TCP/IP,而总是控制着本地网络。Lisp 机器小组的一个成员 David Moon 写的另一个备忘录中提到,Chaosnet “目前并不打算为低速链接、高信噪链接、多路径、长距离链接做特别的优化。” 5 他们专注于打造一个在小型网络里表现极佳的协议。

因为 Chaosnet 连接在 Lisp 处理器和文件系统之间,所以速度十分重要。网络延迟会严重拖慢一些像打开文本文档这种简单操作的速度,为了提高速度,Chaosnet 结合了在 Network Control Program网络控制程序中使用的一些改进方法,随后的 Arpanet 项目中也使用了这些方法。据 Moon 所说,“为了突破诸如在 Arpanet 中发现的速率瓶颈,很有必要采纳新的设计。目前来看,瓶颈在于由多个链接分享控制链接,而且在下一个信息发送之前,我们需要知道本次信息已经送达。” 6 Chaosnet 协议族的批量 ACK 包跟当今 TCP 的差不多,它减少了 1/3 到一半的需要传输的包的数量。

因为绝大多数 Lisp 机器使用较短的单线进行连接,所以 Chaosnet 可以使用较为简单的路由算法。Moon 在 Chaosnet 路由方案中写道“预计要适配的网络架构十分简单,很少有多个路径,而且每个节点之间的距离很短。所以我认为没有必要进行复杂的方案设计。” 7 因为 Chaosnet 采用的算法十分简单,所以实现它也很容易。与之对比明显,其实现程序据说只有 Arpanet 网络控制程序的一半。 8

Chaosnet 的另一个特性是,它的地址只有 16 位,是 IPv4 地址的一半。所以这也意味着 Chaosnet 只能在局域网里工作。Chaosnet 也不会去使用端口号;当一个进程试图连接另一个机器上的另外一个进程时,需要首先初始化连接,获取一个特定的目标“ 联系名称 contact name ”。这个联系名称一般是某个特定服务的名字。比方说,一个主机试图使用 TELNET 作为联系名称,连接另一个主机。我认为它的工作方式在实践中有点类似于 TCP,因为有些非常著名的服务也会拥有联系名称,比如运行在 80 端口上的 HTTP 服务。

在 1986 年,RFC 973 通过了将 Chaosnet DNS 类别加入域名解析系统的决议。它替代了一个早先出现的类别 CSNETCSNET 是为了支持一个名叫 计算机科学网络 Computer Science Network 而被制造出来的协议。我并不知道为什么 Chaosnet 能被域名解析系统另眼相待。很多别的协议族也有资格加入 DNS,但是却被忽略了。比如 DNS 的主要架构师之一 Paul Mockapetris 提到说在他原本的构想里, 施乐 Xerox 的网络协议应该被包括在 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 选题:lujun9972 译者:acyanbird 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

6 位专家为你解析 DevOps 及其实现、实践和哲学的关键。

如果你问 10 个人关于 DevOps 的问题,你会得到 12 个答案。这是对于 DevOps 的意见和期望的多样性的结果,更不用说它在实践中的差异。

为了解读 DevOps 的悖论,我们找到了最了解它的人 —— 这个行业的顶尖从业者。这些人熟悉 DevOps,了解技术的来龙去脉,并且已经有了多年 DevOps 实践。他们的观点应该能鼓励、刺激和激发你对 DevOps 的想法。

DevOps 对你意味着什么?

让我们从基本原理开始。我们不能只在教科书上寻找答案,而应该需要知道专家们怎么说。

简而言之,专家们说的是关于 DevOps 的原则、实践和工具。

IBM 数字企业集团 DevOps 商业平台领导者 Ann Marie Fred,说,“对于我来说,DevOps 是一套实践和原则,旨在使团队在设计、开发、交付和操作软件方面有更好的效率。”

据红帽资深 DevOps 布道者 Daniel Oh,“通常来说,DevOps 促使企业基于当前的 IT 发展与应用开发、IT 运维和安全协议的流程和工具。”

Tactec 战略解决方案的创始人 Brent Reed,谈及了利益相关者的持续改进,“DevOps 对我来说意味着包括了一种思维方式的工作方式,它允许持续改进运维绩效,进而提升组织绩效,从而让利益相关者受益。”

许多专家也强调 DevOps 文化。Ann Marie 说,“这也是持续改进和学习的问题。它涉及的是人和文化,以及工具和技术。”

美国保监会 (NAIC) 首席架构师兼 DevOps 领导者 Dan Barker,“DevOps 主要是关于文化…它将几个独立的领域聚集在一起,如精益生产、公正文化 和持续的学习。我认为文化是最关键和最难执行的。”

Atos 的 DevOps 负责人 Chris Baynham-Hughes,说,“[DevOps] 实践是通过组织内的文化、流程和工具的发展而被采用的。重点是文化变革,DevOps 文化借鉴的关键是协作、试验、快速反馈和持续改进。”

云架构师 Geoff Purdy,谈及敏捷和反馈,“缩短和放大反馈回路。我们希望团队在几分钟内而不是几周内获得反馈。”

但在最后,Daniel 通过解释开源和开源文化是如何让他以简单快捷的方式实现目标来强调这点,“在推动 DevOps 中,最重要的事情应该是开源文化而不是具体的工具或复杂的解决方案。”

你认为哪些 DevOps 实践有效?

专家列举的那些最佳实践是普遍存在的,但又各不相同。

Ann Marie 表示:“一些十分强大灵活的项目管理[实践],能在职能、独立的小组之间打破壁垒;全自动化持续部署,蓝/绿部署实现零时间停机状态;开发人员设置自己的监控和警告,无缝自我修复,自动化的安全性与合规性。”

Chris 说,“特别的突破是倾情合作、持续改进、开放领导、缩短业务距离、从垂直孤岛转向横向/跨功能的产品团队、工作透明化、相互影响、Mobius 循环、缩短反馈回路、自动化(从环境到 CI/CD)。”

Brent 支持“发展学习文化,包括 TTD [测试驱动开发] 和 BDD [行为驱动开发]捕获事件,并通过持续集成和持续交付从设计、构建和测试到实施在生产环境上一系列事件的自动化。测试采用故障优先的方法,能够自动化集成和交付流程,并在整个生命周期中包含快速反馈。”

Geoff 强调自动化配置。“选择一个自动化配置,对我的团队来说非常有效。更具体地说从版本控制代码库中自动配置。”

Dan 则玩的开心,“ 我们做了很多不同的事情来建立 DevOps 文化。我们举办 ‘午餐 & 学习’ 活动,提供免费的食物来鼓励大家一起学习。我们买书,分组学习。”

你如何激励你的团队实现 DevOps 这个目标?

Daniel 强调“自动化的问题就是为了减少 DevOps 计划中来自多个团队的异议,你应该鼓励你的团队提高开发、测试与 IT 运营的自动化能力,以及新的流程和程序。例如,Linux 容器是实现 DevOps 自动化功能的关键工具。”

Geoff 很是赞同,“机械化的劳作,你有讨厌现在做的任务吗?很棒。如果可能的话,让它们消失。不行,那就让它们自动化。它能使工作不会变得太枯燥,因为工作总是在变化。”

Dan、Ann Marie 和 Brent 强调团队的执行力。

Dan 说,“在 NAIC,我们有个很好的奖励系统来鼓励特定的行为。我们有多个级别的奖项,其中两个奖项可以由任何人颁布给某人。我们也会颁奖给完成重要任务的团队,但我们通常只奖励给个人贡献者。”

Ann Marie 表示,“我所在地区的团队最大的动力是看见其他人成功。我们每周都会彼此回放一次,其中一部分是分享我们从尝试新工具或实践中学到的东西。团队热衷于他们现在做的事情,并愿意帮助其他人开始,相信更多的团队很快也会加入进来。”

Brent 表示赞同。“让每个人学习,并掌握同样的基础知识至关重要……我喜欢从评估什么能帮助团队实现目标[以及]产品负责人和用户需要提供的内容入手。”

Chris 推荐采用双管齐下的方法。“运行可以每周可以实现的小目标,并且[在这]可以看到他们正在运做的功能工作之外的进展,庆祝你所取得的进步。”

DevOps 和敏捷开发如何协同工作?

这是一个重要的问题,因为 DevOps 和敏捷开发都是现代软件开发的基石。

DevOps 是一个软件开发的过程,专注与沟通与协作,以促进快速部署应用程序和产品。而敏捷开发是一种开发方法,涉及持续开发、连续迭代和连续测试,以实现可预测和可交付的成果质量。

那么,它们又有怎样的联系?让我们去问问专家吧。

在 Brent 来看,“DevOps != 敏捷。其次 敏捷 != Scrum 流程……敏捷工具和工作方式支撑着 DevOps 策略和目标,它们是如此融合在一起的。”

Chris 说,“对我而言敏捷是 DevOps 的一个基本组件。当然,我们可以讨论如何在非敏捷开发环境中采用 DevOps 文化,但最终表明,提高软件设计方式的灵活性是采用 DevOps 成熟读的一个关键指标。”

Dan 将 DevOps 与更伟大的 敏捷宣言 联系起来。“我在谈到敏捷时总会引用敏捷宣言来设置基准,而有许多实现中并不关注该宣言。当你阅读这份宣言时,你会发现它确实从开发的角度描述了 DevOps。因此,将敏捷融入 DevOps 文化非常容易,因为敏捷关注于沟通、协作、变化的灵活性以及快速地投入生产。”

Geoff 认为 “DevOps 是敏捷实施的众多实现之一。敏捷本质上是一套原则,而 DevOps 则是体现这些原则的文化、流程和工具链。”

Ann Marie 简洁说明,“敏捷是 DevOps 的先决条件。DevOps 使敏捷变得更加有效。”

DevOps 是否受益于开源?

这个问题得到了所有参与者的热烈肯定,然后解释了他们看到的好处。

Ann Marie 说,“我们站在巨人的肩膀上,在已有的基础之上发展。拉取请求和代码评审的开源模式,对 DevOps 团队维护软件很有效果。”

Chris 赞同 DevOps “毫无疑问”受益于开源。“从设计和工具方面(例如,Ansible),到流程和人员方面,通分享行业内的故事和开源社区的领导。”

Geoff 提到一个好处是“基层的采纳”。免费的软件不需要签署购买申请。团队发现了满足他们需求的工具,可以自行进行修改。[然后]在它之上构建,并为更大的社区提供更好的功能。如此往复。

开源已经向 DevOps 展示着“就像开源软件开发者正在做的那样,采用更好的方式来克服新的变化”,Daniel 说。

Brent 同意道 “DevOps 从开源中获益良多。一种方法是使用这些工具来理解它们是如何加速 DevOps 的目标和策略;在自动化、自动伸缩、虚拟化和容器化等关键方面对开发人员和操作人员进行培训,如果不引入使 DevOps 更加容易的技术支持,就很难实现这些特性。”

Dan 指出了 DevOps 和开源之间的双向共生关系,“做好开源需要 DevOps 文化。大多数开源项目都具有非常开放的沟通结构,很少有不透明的地方。对于 Devops 实践者来说,这实际上是一个很好的学习机会,可以让他们了解到可能需要将什么引入自己的组织中。此外能够使用来自社区与组织类似的工具来鼓励自己的文化成长。我喜欢用 GitLab 作为这种共生关系的一个例子。当我把 GitLab 带入一家公司时,我们得到了一个很棒的工具,但我们真正购买的是他们独特的文化,通过我们与他们的互动以及我们的贡献带来了巨大价值。他们的工具也可以为 DevOps 组织提供更多东西,而他们的文化已经在我引入它的公司中引起了他们的敬畏。”

现在我们的 DevOps 专家已经参与进来了,请在评论中分享你对 DevOps 的理解,以及向我们提出其他问题。


via: https://opensource.com/article/19/1/what-does-devops-mean-you

作者:Girish Managoli 选题:lujun9972 译者:MZqk 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

若你遵守这些最佳实践,Internet Relay Chat(IRC)会议可以很好滴推进项目进展。

开展任何形式的会议都是门艺术。很多人已经学会了开展面对面会议和电话会议,但是 Internet Relay Chat(IRC)会议因其特殊的性质有别于“ 现实 in real life ”(IRL) 会议。本文将会分享 IRC 这种会议形式的优势和劣势,以及帮你更有效地领导 IRC 会议的小技巧。

为什么用 IRC? 虽说现在有大量的实时聊天工具可供选择,IRC 依然是开源项目的基石。若你的项目使用其他沟通工具,也不要紧。这里大多数的建议都适用于同步的文本聊天机制,只需要进行一些微调。

IRC 会议的挑战

与面对面会议相比,IRC 会议会遇到一些挑战。你应该知道一个人结束谈话到下一个人开始谈话之间会有间隙吧?在 IRC 中这更糟糕,因为人们需要输入他们的所想。这比说话要更慢,而且不像谈话,你不知道别人什么时候在组织消息。主持人在要求回复或转到下一主题前必须等待很长一段时间。而想要发言的人需要先插入一个简短的信息(例如,一个句号)来让主持人知道(他需要发言)。

IRC 会议还缺少其他方法中能够获得的那些元数据。你无法通过文本了解面部表情和语调。这意味着你必须小心你的措辞。

而且 IRC 会议很容易让人分心。至少在面对面会议中,当某人正在看搞笑的猫咪图片时,你可以看到他面带笑容而且在不合时宜的时候发出笑声。在 IRC 中,除非他们不小心粘贴了错误的短信,否则甚至都没有同伴的压力来让他们假装专注。你甚至可以同时参加多个 IRC 会议。我就这么做过,但如果你需要积极参与这些会议,那就很危险了。

IRC 会议的优势

IRC 会议也有某些独一无二的优势。IRC 是一个非常轻资源的媒介。它并不怎么消耗带宽和 CPU。这降低了参与的门槛,这对贫困这和发展中的人都是有利的。对于志愿者来说,这意味着他们可以在工作日参加会议。同时它也意味着参与者无需寻找一个安静的地方来让他们沟通而不打扰到周围的人。

借助会议机器人,IRC 可以立即生成会议记录。在 Fedora 中,我们使用 Zodbot(Debian 的 Meetbot 的一个实例)来记录会议并提供交互。会议结束后,会议记录和完整的日志立即可供社区使用。这减少了开展会议的管理开销。

这跟普通会议类似,但有所不同

通过 IRC 或其他基于文本的媒介进行会议意味着以稍微不同寻常的方式来看待会议。虽然它缺少一些更高带宽沟通模式的优点,但它也有自己的优点。开展 IRC 会议可以让你有机会开发出各种规则,而这些规则有助于你开展各种类型的会议。

与任何会议一样,IRC 会议最好有明确的日程和目的。一个好的会议主持者知道什么时候让谈话继续下去以及什么时候将话题拉回来。并没有什么硬性规定,这是一门艺术。但 IRC 在这方面有一个优势。通过设置频道主题为会议的当前主题,人们可以看到他们应该谈论的内容。

如果你的项目尚未实施过同步会议,你应该考虑一下。对于项目成员分布在不同时区的项目,找到一个大家都认可的时间来组织会议很难。你不能把会议作为你唯一的协调方式。但他们可以是项目工作的重要组成部分。


via: https://opensource.com/article/19/2/irc-vs-irl-meetings

作者:Ben Cotton 选题:lujun9972 译者:lujun9972 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

技术团队喜欢 3 月 14 日的圆周率日:你是否知道这也是阿尔伯特·爱因斯坦的生日和 Linux 内核1.0.0 发布周年纪念日?来看一些树莓派的趣事和 DIY 项目。

今天,全世界的技术团队都会为一个数字庆祝。3 月 14 日是 圆周率日 Pi Day ,人们会在这一天举行吃派比赛、披萨舞会,玩 数学梗 math puns 。如果这个数学领域中的重要常数不足以让 3 月 14 日成为一个节日的话,再加上爱因斯坦的生日、Linux 内核 1.0.0 发布的周年纪念日,莱伊·惠特尼在这一天申请了轧花机的专利这些原因,应该足够了吧。(LCTT译注:轧花机是一种快速而且简单地分开棉花纤维和种子的机器,生产力比人手分离高得多。)

很荣幸,我们能在这一个特殊的日子里一起了解有关它的趣事和与 π 相关的好玩的活动。来吧,和你的团队一起庆祝圆周率日:找一两个点子来进行团队建设,或用新兴技术做一个项目。如果你有为这个大家所喜爱的无限小数庆祝的独特方式,请在评论区与大家分享。

圆周率日的庆祝方法:

  • 今天是圆周率日的第 31 次周年纪念(LCTT 译注:本文写于 2018 年的圆周率日,故在细节上存在出入。例如今天(2019 年 3 月 14 日)是圆周率日的第 31 次周年纪念)。第一次为它庆祝是在旧金山的 探索博物馆 Exploratorium 由物理学家 Larry Shaw 举行。“在第 1 次周年纪念日当天,工作人员带来了水果派和茶壶来庆祝它。在 1 点 59 分(圆周率中紧接着 3.14 的数字),Shaw 在博物馆外领着队伍环馆一周。队伍中用扩音器播放着‘Pomp and Circumstance’。” 直到 21 年后,在 2009 年 3 月,圆周率正式成为了美国的法定假日。
  • 虽然该纪念日起源于旧金山,可规模最大的庆祝活动却是在普林斯顿举行的,这个小镇举办了为期五天的许多活动,包括爱因斯坦模仿比赛、掷派比赛,圆周率背诵比赛等等。其中的某些活动甚至会给获胜者提供价值 314.5 美元的奖金。
  • 麻省理工的斯隆管理学院 MIT Sloan School of Management 正在庆祝圆周率日。他们在 Twitter 上分享着关于 π 和派的圆周率日趣事,详情请关注 推特话题 Twitter hashtag #PiVersusPie 。

与圆周率有关的项目与活动:

  • 如果你想锻炼你的数学技能, 美国国家航空航天局 National Aeronautics and Space Administration (NASA)的 喷气推进实验室 Jet Propulsion Lab (JPL)发布了一系列新的数学问题,希望通过这些问题展现如何把圆周率用于空间探索。这也是美国国家航天局面向学生举办的第五届圆周率日挑战。
  • 想要领略圆周率日的精神,最好的方法也许就是开展一个树莓派项目了,无论是和你的孩子还是和你的团队一起完成,都是不错的。树莓派作为一项从 2012 年开启的项目,现在已经售出了数百万块的基本型的电脑主板。事实上,它已经在通用计算机畅销榜上排名第三了。这里列举一些可能会吸引你的树莓派项目或活动:

    • 来自谷歌的 自己做 AI AI-Yourself (AIY)项目让你自己创造一个语音控制的数字助手或者一个图像识别设备
    • 在树莓派上使用 Kubernets
    • 组装一台怀旧游戏系统,目标:拯救桃子公主!
    • 和你的团队举办一场树莓派 Jam。树莓派基金会发布了一个帮助大家顺利举办活动的指导手册。据该网站说明,树莓派 Jam 旨在“给数字创作中所有年龄段的人提供支持,让世界各地志同道合的人们汇聚起来讨论和分享他们的最新项目,举办讲习班,讨论和派相关的一切。”

其他有关圆周率的事情:

  • 当前背诵圆周率的世界纪录保持者是 Suresh Kumar Sharma,他在 2015 年 10 月花了 17 小时零 14 分钟背出了 70,030 位数字。然而,非官方记录的保持者 Akira Haraguchi 声称他可以背出 111,700 位数字。
  • 现在,已知的圆周率数字的长度比以往都要多。在 2016 年 11 月,R&D 科学家 Peter Trueb 计算出了 22,459,157,718,361 位圆周率数字,比 2013 年的世界记录多了 9 万亿数字。据《 新科学家 New Scientist 》所述,“最终文件包含了圆周率的 22 万亿位数字,大小接近 9 TB。如果将其打印出来,能用数百万本 1000 页的书装满一整个图书馆。”

祝你圆周率日快乐!


via: https://enterprisersproject.com/article/2018/3/pi-day-12-fun-facts-and-ways-celebrate

作者:Carla Rudder 译者:wwhio 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

先说一下,我不是一个专业的设计师,但我在 Windows 上使用过某些工具(如 Photoshop、Illustrator 等)和 Figma(这是一个基于浏览器的界面设计工具)。我相信 Mac 和 Windows 上还有更多的设计工具。

即使在 Linux 上,也有数量有限的专用图形设计工具。其中一些工具如 GIMPInkscape 也被专业人士使用。但不幸的是,它们中的大多数都不被视为专业级。

即使有更多解决方案,我也从未遇到过可以取代 Sketch、Figma 或 Adobe XD 的原生 Linux 应用。任何专业设计师都同意这点,不是吗?

Akira 是否会在 Linux 上取代 Sketch、Figma 和 Adobe XD?

所以,为了开发一些能够取代那些专有工具的应用,Alessandro Castellani 发起了一个 Kickstarter 活动,并与几位经验丰富的开发人员 Alberto FanjulBilal ElmoussaouiFelipe Escoto 组队合作。

是的,Akira 仍然只是一个想法,只有一个界面原型(正如我最近在 Kickstarter 的直播流中看到的那样)。

如果它还不存在,为什么会发起 Kickstarter 活动?

Kickstarter 活动的目的是收集资金,以便雇用开发人员,并花几个月的时间开发,以使 Akira 成为可能。

尽管如此,如果你想支持这个项目,你应该知道一些细节,对吧?

不用担心,我们在他们的直播中问了几个问题 - 让我们看下:

Akira:更多细节

Akira prototype interface

图片来源:Kickstarter

如 Kickstarter 活动描述的那样:

Akira 的主要目的是提供一个快速而直观的工具来创建 Web 和移动端界面,更像是 SketchFigmaAdob​​e XD,并且是 Linux 原生体验。

他们还详细描述了该工具与 Inkscape、Glade 或 QML Editor 的不同之处。当然,如果你想要了解所有的技术细节,请查看 Kickstarter。但是,在此之前,让我们看一看当我询问有关 Akira 的一些问题时他们说了些什么。

问:如果你认为你的项目类似于 Figma,人们为什么要考虑安装 Akira 而不是使用基于网络的工具?它是否只是这些工具的克隆 —— 提供原生 Linux 体验,还是有一些非常有趣的东西可以鼓励用户切换(除了是开源解决方案之外)?

Akira: 与基于网络的 electron 应用相比,Linux 原生体验总是更好、更快。此外,如果你选择使用 Figma,硬件配置也很重要,但 Akira 将会占用很少的系统资源,并且你可以在不需要上网的情况下完成类似工作。

问:假设它成为了 Linux 用户一直在等待的开源方案(拥有专有工具的类似功能)。你有什么维护计划?你是否计划引入定价方案,或依赖捐赠?

Akira:该项目主要依靠捐赠(类似于 Krita 基金会 这样的想法)。但是,不会有“专业版”计划,它将免费提供,它将是一个开源项目。

根据我得到的回答,它看起来似乎很有希望,我们应该支持。

总结

你怎么看 Akira?它只是一个概念吗?或者你希望看到进展?

请在下面的评论中告诉我们你的想法。


via: https://itsfoss.com/akira-design-tool

作者:Ankush Das 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

非标准的开源贡献者许可协议正在创造类似电影《冲出人魔岛》中“人魔”般的怪物。

当我开启作为开源律师的职业生涯时,面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增,正如我的同事 Scott Peterson 在其文章中所述,“开源许可协议是共享资源”:

专注于少数许可协议更有好处。通过对少数许可协议达成更广泛共识所积累的经验和讨论更容易减少不确定性,而不是在成千上百的许可协议之间进行有关行动和辩论。

过去多年开源社区对许可协议扩散的反应持积极态度,我很高兴看到大多数开源项目都从一组被工程师和律师熟知的许可协议(例如 GPL、LGPL、AGPL、BSD、MIT、Apache 2)中进行选择。因此,不用将时间浪费在解释许可协议条款上,完全开启了一个低摩擦的生态系统。

一旦项目采用开源许可协议,它通常采用标准的“ 入站=出站 inbound=outbound ”模式,创造该短语的 Richard Fontana 将其描述为贡献者不言自明地获得出站项目适用的许可协议的许可,使得贡献者可以轻松参与项目,无需担心繁文缛节和受到威胁。这是一个非常简单的模式,能够非常聪明地进行上面提到的许可协议选择。

不幸的是,许多项目不选择采用“入站=出站”模式,而是采用某种形式的《 贡献者许可协议 Contributor License Agreement 》(CLA)。CLA 的范围和目的各不相同。读者们可以在 Ben Cotton 的文章《CLA 与 DCO 有什么不同?》中具体了解《贡献者许可协议》与《 开发者原创证书 Developer Certificates of Origin 》(DCO)的区别。

采用 CLA 的项目在接受贡献之前,要求贡献者提交作为个人或所在公司签署的 CLA 存档。除非是其条款能够被工程师和其代理律师很好理解的标准 CLA(例如下文提到的 Apache 软件基金会非实质性定制的 CLA),否则因为需要非常仔细阅读 CLA 以确保能够完全理解其条款,贡献者通常放弃去深究 CLA。理解非标准 CLA 的过程需要数天或上周才能完成,具体取决于工作负荷以及是否需要与许可协议提交人进行协商。根据我的经验,最终结果是回到标准的 CLA 条款!这个曲折的过程导致大量的时间和精力被浪费。此外,CLA 需要某种形式的签名,增添了许多在大型官僚组织可能更严重的延迟性和复杂性。这并不是一条令人开心的路径,对开源/协作开发模式具有高度侵蚀性。

请注意,当我提到“标准 CLA”时,我所指的是基于众所周知 CLA(例如 Apache 软件基金会个人或企业 CLA)的 CLA。虽然 Apache 软件基金会的 CLA 由基金会本身以其原始形式使用,但它们通常被以非实质性方式进行修改以供其他组织使用。例如,大多数组织在开始时都小心翼翼地摆脱了许可协议的慈善使命,还定制了许可协议名称。Apache 软件基金会这类非实质性变体需要与本文中描述的类似“人魔”怪物的变体区分开。

我对最近 CLA 数量的激增表示担忧,我们似乎正在经历十年前在开源许可协议扩散方面遇到的相同现象。事实上,在过去的一年里,在我的办公桌上至少看到 20 种不同的 CLA,它们与常见的 Apache 软件基金会个人或企业 CLA 存在细微但实质性的偏差。这些偏差通常小到无助于澄清条款语言或权利,但其中有些偏差会比较大,这种混合的可憎之物让我想起了 Moreau 博士通过他的活体解剖过程创造的新动物(参见维基百科上的《冲出人魔岛》)。无论偏差是小还是大,它们造成的影响可能很大,经常导致混淆、更多的审查时间以及谈判。

例如,律师普遍接受的做法是对许可协议或合同中的术语使用初始定义。无意中使用同一术语的小写形式会导致是否应该使用该术语在标准/字典中定义或协议中更窄或更宽泛定义的模糊性。尽管这对于不经意的观察者来说似乎是一个微不足道的偏差,但这通常会导致许可协议接收/授予的权限显著减少或扩大,或者导致不可接受的歧义。其他偏差起草得如此之差,以至于它们的意义不明确,因此必须彻底拒绝。

在最近的例子中,有一种 CLA 的专利许可语言以令人困惑的方式将术语 “衍生作品” derivative works 包括在内,偏离了 Apache 软件基金会 CLA 版本。此 CLA 授予专利许可的范围似乎过于宽泛且可能无限制,它是如此模糊,以至于我被迫拒绝使用它。我不确定这是否是这个特定 CLA 的起草人所预期的结果,但是这次审查花费了大量的时间和成本,最终限制了我们的工程师为该项目做出贡献。这是一个令人伤心的结果,没有人从中受益。

作为一个社区,让我们从之前关于开源许可协议扩散的错误中吸取教训,采用“入站=出站”模式,最好使用 DCO 而不是 CLA。如果您选择使用 CLA,那么强烈建议使用 Apache 软件基金会个人或企业 CLA 等标准 CLA,而不是创建新的、幻想的或荒谬的类似“人魔”怪物的许可协议。

作者简介:Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 Red Hat 公司的开源知识产权律师,还担任 托马斯杰斐逊法学院 Thomas Jefferson School of Law 的兼职教授。在任职 Red Hat 之前,Jeffrey 曾担任 高通公司 Qualcomm Incorporated 的专利顾问,为 首席科学家办公室 Office of the Chief Scientist 提供开源事务咨询。

译者简介:薛亮,集慧智佳知识产权咨询公司总监,擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。