分类 观点 下的文章

大家好,我是白宦成(@bestony),前几天在 B 站直播写 ClubHouse 复刻版的开发者。当然,除了这个身份,在真实生活中,我还是 Linux 中国开源社区的技术负责人,负责开发我们自己的自用工具和平台。

作为一个 indiehacker(自诩的),我想和大家一起来复盘一下,这一次的直播活动和意料之外的爆火。

为什么要做 NESHouse

我其实想到复刻 ClubHouse 的时间是非常早的,我是在 2 月 1 日拿到了 ClubHouse 的邀请码,在试玩了一段时间以后,就觉得这个软件还不错,理念很有意思,但并没有太在意,放在了一边。可到了晚上,因为知道 Elon Musk 要来做分享,作为一个比较欣赏他的人,我自然不能错过,但遗憾的是,当我打开 ClubHouse 的时候,已经有太多的人涌入这个 App,几乎无法使用,总是不停的卡顿。

这时让我产生了怀疑:这个东西到底有多少的工作量?为什么这么容易性能卡顿?

结合实际的使用发现,有些时候,我可以正常聊天,但是却会报错,可以发现问题不在语音服务,而是在 ClubHouse 自身的业务能力不足以支撑超过预期的访问量

我上一份工作是在一家云计算企业工作,所以相对来说,对云计算产品有一定的了解。在我看来,这样的一个产品的增量,很难把现有的云计算产品的服务容量打穿,你能想象 ClubHouse 把 AWS、GCP、Azure 等云服务厂商打穿么?

我觉得,要么是开发者的大规模服务的架构经验不足,虽然用了云,但是没设计好,无法充分适应弹性;要么是开发者没有对超过预判的访问量做的预案不足。

这就让我思考,我能否复刻一个 ClubHouse?用一些更加具有弹性的服务?给大家打个样? 云计算是好,但用起来也要姿势对,才能不出问题。

72 小时复刻一个 ClubHouse,是一个什么概念?

既然要复刻项目,自然要做的不能和碰瓷的一样(这里鄙视几家碰瓷的 App,拿很久之前写的具备了语音聊天的 App,来碰瓷 ClubHouse)。

但我又不希望在这个事情上花费太多的事情,我还有很多更重要的事情要做,所以我选择了 72 小时。48 小时或 24 小时是一般的黑客松的时间长度,但我确实又不熟悉这个项目,所以用 72 小时比较稳妥。

于是便立了一个 Flag ,说我要在 72 小时内,复刻一个 ClubHouse。立了个 Flag,说干就干。关于这 72 小时,我希望可以强调两点,也希望这两点能够帮助到你。

1. 明确自己要做的和不要做的

我的时间和精力以及资源都有限,所以并不是什么东西我都能要的。比如在做复刻的时候,考虑到我如果开发原生的 App 或者小程序,就需要提交审核。那我就不能选择做 App,不然 72 小时到了,审核还没过,就食言了。也是出于审核的考虑,我最终选择了使用 Web 的方式来开发 NESHouse

而到了具体的功能特性层面,受限于 Web 和 App 的机制不同,我很难要求用户必须做什么样的操作,也很难确保 App 响应什么样的功能,因此,我对于 ClubHouse 的功能进行了一些删减,邀请上台之类的功能,我就选择性的先不做,将重点放在更加重要的功能中。

在开发黑客松项目的时候,一定要先想清楚自己要什么,不要什么,这样才能确保自己在给定的时间内完成自己的工作。不然大概率会发现时间马上要截止,但核心功能还没有研发完成。

2. 选择一些新的、以后可能会用到的技术

在这次项目开发的时候,我选择的前端技术栈并非我过去惯用的 React、Vue ,而是一个相对小众 JS 框架的 Alpine.js。

选择 Alpine.js 的原因很简单,我后续需要在其它的项目上使用这个框架,但我此刻确实也不熟悉。如果我在这 72 小时里把这个工具用了一遍,如果评估觉得不错,我就可以在后续的项目中使用,如果这次我用的不太好,那我损失的也只有 72 小时,比在正式项目中使用的损失成本要低很多

而在另外的两个服务,选择起来就简单多了:

  • LeanCloud 的云服务我使用了很多年,使用体验也很不错,而且他们这种 Serverless 云服务,可以让我在开发 NESHouse 的时候,免于去写很重的部署和基础逻辑,更加专注在业务逻辑上。
  • 音频服务我则选择了国内用户比较多,开发起来也比较方面的声网,声网的 API 比较简单, NESHouse 中的声网音频接入只用 4 行代码就实现了。

除此之外,便是使用了 NES.css 这样的 CSS 框架,来让这个项目更加的有趣,更加的 Funny。

对于开发黑客松项目的时候,可以想想自己能否接受这一次的失败,如果可以接受自己的失败,不妨将这次黑客松看做是一次玩的机会,玩一玩新的技术,就算失败了,也不过是损失给定的时间。但如果你在工作项目中出现了问题,损失可就大了。

总结

72 个小时的复刻对于我来说不算难,实际上我也只花了 55 个小时就复刻成功了。但更难的,是如何让一个开源项目持续的成长下去,持续的获得用户、获得关注。

最后,大家感兴趣的话,可以移步复刻这个项目,看看你能不能做一个自己的 ClubHouse: https://github.com/bestony/neshouse

自动化是美好的,但也不总是那样。确保你的电子邮件自动回复和抄送配置正确,这样你就不会浪费大家的时间。

 title=

在前几年,这个年度系列涵盖了单个的应用。今年,我们除了关注 2021 年的策略外,还将关注一体化解决方案。欢迎来到 2021 年 21 天生产力的第十七天。

好了,我们已经谈到了一些我们应该对电子邮件做的事情:不要再把它当作即时通讯工具优先处理事情努力达到收件箱 0 新邮件,以及有效过滤。但哪些事情是我们不应该做的呢?

Automated email reply

你真幸运 (Kevin Sonney, CC BY-SA 4.0

1、请不要对所有事情自动回复

邮件列表中总有些人,他们去度假了,并设置了一个“我在度假”的自动回复信息。然而,他们没有正确地设置,所以它对列表上的每一封邮件都会回复“我在度假”,直到管理员将其屏蔽或取消订阅。

我们都感受到了这种痛苦,我承认过去至少有一次,我就是那个人。

从我的错误中吸取教训,并确保你的自动回复器或假期信息对它们将回复谁和多久回复一次有限制。

An actual email with lots of CC'd recipients

这是一封真实的电子邮件 (Kevin Sonney, CC BY-SA 4.0

2、请不要抄送给所有人

我们都至少做过一次。我们需要发送邮件的人员众多,因此我们只需抄送他们所有人。有时这是有必要的,但大多数时候,它并不是。当然,你邀请每个人在庭院吃生日蛋糕,或者你的表姐要结婚了,或者公司刚拿到一个大客户,这都是好事。如果你有邮件列表的话,请用邮件列表,如果没有的话,请给每个人密送。说真的,密送是你的朋友。

3、回复所有人不是你的朋友

 title=

这一条与上一条是相辅相成的。我不知道有多少次看到有人向一个名单(或者是一个大群的人)发送信息,而这个信息本来是要发给一个人的。我见过这样发送的相对好的邮件,以及随之而来的纪律处分邮件。

认真地说,除非必须,不要使用“回复全部”按钮。即使是这样,也要确保你真的需要这样做。

有些电子邮件应用比其他应用管理得更好。Kmail,KDE Kontact 的电子邮件组件,在回复工具栏按钮的子菜单中,有几个不同的回复选项。你可以选择只回复给发件人字段中的任何实体(通常是一个人,但有时是一个邮件列表),或者回复给作者(在抄送或密送中去除每一个人),或者只回复给一个邮件列表,或者回复所有人(不要这样做)。看到明确列出的选项,的确可以帮助你了解谁会收到你要发送的邮件副本,这有时比你想象的更发人深省。我曾经发现,当我意识到一个评论并不一定会对一个复杂的讨论的最终目标有所帮助时,我就会把邮件的收件人改为只是作者,而不是整个列表。

(另外,如果你写的邮件可能会给你的 HR 或公司带来麻烦,请在点击发送之前多考虑下。——

希望你已经不再在电子邮件中这么做了。如果你认识的人是这样的呢?欢迎与他们分享。


via: https://opensource.com/article/21/1/email-mistakes

作者:Kevin Sonney 选题:lujun9972 译者:geekpi 校对:wxy

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

保留简略的版权声明即可,无需投入过多资源维护。

版权声明 Copyright Notice 在源代码中的应用并不一致且维护不善,结果导致它无法成为良好的信息来源。那是否应该投入更多资源来维护版权声明呢?答案是不需要。

版权声明是单行字符串,通常包括单词“版权”(或某些替代词,如 ©)、名称(通常是个人或公司)和年份。

在本文中,我不关注许可证或许可证声明(有时可能包括版权声明)。我关于版权声明维护的资源投入应该保持低优先级的建议不适用于许可证信息。许可证信息应清晰呈现并保持准确。如果你邀请其他人使用你的软件并对其进行操作,请通过提供并维护清晰的许可证信息来明确其授予的权限。

再说回版权声明:它们的法律意义是什么呢?如果你认为版权声明符合法律要求或至少提供了重要的法律权益,请三思。此类声明在开源软件中的法律意义是如此之小,以至于人们可以轻易地找到超出其法律意义的实际做法。

尽管此类声明可能看起来很重要,但它们在当今源代码中的存在很大程度上是过去美国版权法的残余影响。曾经有一段时间,如果未在已出版的材料中包含版权声明,依据美国版权法,版权人可能会完全丧失权利;当美国最终加入《伯尔尼公约》并成为缔约国时,情况发生了变化(美国于 1988 年 11 月 16 日加入该条约,并于 1989 年 3 月 1 日在美国生效)。

如果开源软件中的此类声明要想具备实效,则一个项目可以采用能够以更少的投入来维护并且仍然获得一些实用价值的约定,不必为了满足美国对“版权声明”的法定要求而去维护版权声明。

由于美国版权法一直是推动版权声明使用的重要因素,因此我将在此进行更深入的探讨。美国版权局发布了名为《通函-3号-版权声明》的指导文件,包括:

“在 1989 3 1 日之前首次出版的所有作品都必须放置版权声明,但下面讨论的某些情况例外。如果省略了该声明或在使用该声明时出现了错误,则通常该作品在美国将失去版权保护。版权声明对于 1989 3 1 日或之后出版的作品、未出版的作品和外国作品是可选的;但是,将版权声明包括在你的作品中将享有法律权益。”

上面我加粗强调的那句话清楚地表明,在 1988 年的美国,版权声明就非常重要。但是,当美国与其他许多国家一起加入《伯尔尼公约》时,美国法律对版权声明的关键作用被消除了。公约规定:“享有和行使这些权利不需经过任何手续……”

麻省理工学院的软件项目(The X Window System)和加州大学伯克利分校的软件项目(Berkeley Software Distribution)中诞生了早期的开源许可证文本,彼时严格的“放置版权声明否则丧失权利”要求仍然有效(或至少在为这些许可证文本做出贡献的人们心中是明确的)。诞生于这种时机的结果是,许可证文本中仍存在有关复制版权声明的明确描述。

随着基于早期文本的许可证的继续广泛使用,大多数开源软件开发人员已经看到,版权声明似乎在许可证中显得很重要。但是这些文本是在考虑较早的法律制度的情况下创建的。现在,距《伯尔尼公约》(大多数其他国家已经接受)的“无需手续性要求”规定首次适用于美国的时间已经过去 30 年了。要了解《伯尔尼公约》的通过程度,请参阅管理该公约的世界知识产权组织维护的缔约方清单

你可能想知道上面引用中提到的那些“法律权益”具体指什么,答案在 3 号通函的末尾:

尽管对于未出版的作品、外国作品或于1989年3月1日或之后出版的作品,版权声明是可选的,但使用版权声明具有以下好处:

  • 版权声明使潜在用户意识到该作品拥有版权。
  • 对于已发表的作品,版权声明可能会阻止版权侵权诉讼中的被告试图减轻其基于无辜侵权辩护的损害赔偿或禁令救济的责任。
  • 版权声明标识了在首次发布作品时版权所有者的权利,供寻求使用该作品的许可方使用。
  • 版权声明标识首次出版的年份,对于匿名作品、假名作品或出租作品而言,可用于确定版权保护期限。
  • 版权声明可能会通过标识版权所有者并设定版权期限来防止其成为孤儿作品。

上面就是所谓的那些“法律权益”。

我引用了美国版权局第 3 号通函,因为与基本法规相比,它对要求的措辞更具可读性。美国联邦一级的成文法被编入所谓的《美国法典》,该法典被组织为一组 “卷” Title 。第 17 卷是版权。版权声明的详细信息位于该卷的第 401-406 部分。可以从 17 USC 401 开始。在版权声明中需包含三个要素描述的有关法规要求,请参见 17 USC 401(b)。如果要查看“疏忽对无辜侵权者的影响”的详细信息,请参见 17 USC 405(b)

为了提供更准确的信息,为什么不清理代码库中的版权声明?尴尬的是,17 USC 506(c)(欺诈性版权声明)17 USC 506(d)(欺诈性删除版权声明)17 USC 1202(a)(虚假版权管理信息)提供了一些不利因素(即使仅限于不良意图)。由于价值较低且存在一定风险(如果在进行更改时出错),因此难怪没有更多资源用于维护版权声明。

有些人和一些公司强调将详细的版权声明放入根据开源许可证提供的代码中。其他人则没有。随着开源项目的发展,某些贡献中可能包含版权声明,而其他贡献则没有。即使文件的内容与原始版本相比发生了很大的变化,文件也可以包含原始版权声明,而不包含其他版权声明。或者以后的贡献者可以向以前没有版权声明的文件中添加一个版权声明。那作为版权声明要素的“该作品的首次出版年份”呢?这意味着什么?不同的人有不同的做法。已更新?那其他贡献提交之后呢?

至于从挖掘版权声明数据中得出结论,要谨慎。期望值不要那么高。

那开源项目应该怎么做呢?

请提供并维护清晰、准确的许可证信息。

对于版权声明来说,很难证明为维护版权声明的详细信息而进行的投入是合理的。但是有些人可能希望会出现版权声明。至于“软件的起源”,也许仅仅参考项目本身而不是尝试捕获更细粒度的内容可能会更有用和更准确。公开年份?手动维护源文件中的麻烦程度导致其不大值得;源管理工具以较低的资源成本提供了更准确的信息。

有关实用方法的更多详细信息,我建议你将注意力集中在对版权声明实践的重新思考上,可以参考 Steve Winslow 于 2020 年 1 月 10 日发布的《开源软件项目中的版权声明》。


作者简介:Scott Peterson 是红帽公司(Red Hat)法律团队成员。很久以前,一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议,这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

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

2020 年 7 月 21 日,Linux 中国翻译团队 LCTT 旗下的第一个特别兴趣小组(SIG)—— LCRH,在红帽公司的鼎力支持下诞生。LCRH 的目标是翻译红帽公司《代码英雄》播客的脚本为适合国人阅读理解的中文脚本。

而到了半年后,LCRH 翻译的中文脚本已经正式更新发布了前三季节目,共计 24 篇文章,时长约 12 个小时,篇幅长达 25 万字,堪比一本长篇小说!

《代码英雄》的英文名为《Command Line Heroes》,作为红帽(Red Hat)公司精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者们是如何彻底改变技术前景的真实史诗。在这一目前仍在持续更新的系列播客中,红帽公司邀请了诸多亲历了开源技术发展史上一些关键事件的人物和代表性的业界技术领袖,来一同探讨开源、操作系统、容器等或源远流长、或鲸吞天下的开源技术。在将这个播客在引入中国时,红帽公司希望其能展现出这些顶级黑客、开发领袖的英姿风貌,因而将其中文名称定名为《代码英雄》。

让这些代码英雄的风貌传播给中国开源和技术爱好者的,是来自 LCRH 的 30 多位贡献者,他们通过自己的辛苦努力,对每一篇文章都经过多人、多次的反复斟酌,力求将代码英雄们的史诗传奇介绍给国人,带给广大的技术开发者。

以下是我们已经发布的前三季的《代码英雄》,更多精制译文正在贡献者们的努力下逐渐加工出来。

在 LCRH 的代码仓库中,记录了 35 名贡献者的 460 次代码提交。这些贡献者们有的人尚在高校,有的人已从业多年;有的人身在中国,有的人求学海外。但对于开源技术的热爱、对于开源贡献的坚持,让他们造就了 LCRH,造就了中文版的《代码英雄》。

作为一个开发者,《代码英雄》所讲述的历史让我悠然神往,技术领袖们对开源和技术的观点使我可以高屋建瓴地看清乱花迷眼的技术本质。而这一切,都是由 LCTT/LCRH 的贡献者带来的,感谢这些可爱的贡献者!

《代码英雄》SIG 欢迎对于开源和技术感兴趣的你,参与到我们当中来,和我们一起贡献代码英雄的世界!你可以在 QQ 中搜索群 940139452,加入我们,参与贡献,具体贡献流程可以进群后了解。

除了《代码英雄》SIG,如果你对技术翻译感兴趣,也愿意以这种方式参与开源贡献,也欢迎加入到 LCTT(Linux 中国翻译团队)当中来。同样的,在 QQ 中搜索群:198889102 即可加入我们,加群时请说明是“志愿者”,并在加入群后修改群名片为你的 GitHub 的 ID,参与贡献!

写日记有着悠久的历史。这里有三个开源工具,可以帮助你写日记变得更轻松。

 title=

在前几年,这个年度系列涵盖了单个的应用。今年,我们除了关注 2021 年的策略外,还将关注一体化解决方案。欢迎来到 2021 年 21 天生产力的第十天。

在我的小学时代,商业互联网还没有出现,老师经常会给我们班级布置一个让我们写日记的作业。有时会针对一些特定的内容,例如特定格式的虫子列表和说明,或者是公民课的每周新闻摘要。

几个世纪以来,人们一直在写日记。它们是一种方便的信息保存方式。它们有很多形式,比如意大利的 Zibaldone备忘录,或者记录今天做了什么的事件日记。

 title=

(Kevin Sonney, CC BY-SA 4.0

为什么我们要写某种日记呢?第一个原因是为了让我们不至于把所有的事情都记在脑子里。我们中没有多少人有 遗觉记忆 Eidetic memory ,维护运行日记或一组笔记可以让我们更容易地参考我们之前做的一些事情。日记也更容易分享,因为它们可以在聊天、邮件中复制/粘贴。正如 Robert Boyce 的名言:“知识就是力量。知识共享使力量倍增。”知识的共享是开源的一个内在组成部分。

 title=

今天的日记 (Kevin Sonney, CC BY-SA 4.0

在写事件日记的时候,有一个很关键的点就是要快速、简单、方便。最简单的方法是打开文档,添加一行当前日期和备注,然后保存。

有几个程序或附加软件可以让这一切变得更简单。GNote 的 Note of the Day 插件会自动创建一个以日期为标题的笔记,可以用来保存当天的内容。

Emacs Org 模式有一个热键组合,可以“捕捉”事物并将其放入文档中。结合 org-journal 附加组件,这将在文档中创建当天的条目。

Kontact 的 KNotes 组件会自动将日期和时间添加到新笔记中。

 title=

查找笔记 (Kevin Sonney, CC BY-SA 4.0

写日记或记录事情是一种方便的方法,可以记录做了什么和怎么做的。它的作用不仅仅是“我做了什么”,它还可以包括阅读的书籍、吃过的食物、去过的地方,以及一大堆对未来有用的信息。


via: https://opensource.com/article/21/1/open-source-journal

作者:Kevin Sonney 选题:lujun9972 译者:geekpi 校对:wxy

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

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽(Red Hat)精心制作的原创音频播客,讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客《代码英雄》第三季(8):C 语言之巨变音频脚本。

导语:C 语言和 UNIX 是现代计算的根基。我们这一季介绍的许多语言都与 C 语言有关,或者至少受到 C 语言的影响。但是 UNIX 和 C 都只是 贝尔实验室 Bell Labs 的几个开发人员作为秘密计划项目创造出来两个成果而已。

贝尔实验室是二十世纪中期的一个创新中心。Jon Gertner 将其描述为一个“创意工厂”。他们在二十世纪 60 年代最大的项目之一是帮助建立一个名为 Multics 的 分时 time-sharing 操作系统。Joy Lisi Rankin 博士解释了当时关于分时系统的一些宣传,它被描述为有可能使计算成为一种公共服务。大型团队投入了数年的精力来构建 Multics —— 但这并不是他们所希望的成果。贝尔实验室在 1969 年正式远离了分时系统。但正如 Andrew Tanenbaum 所描述的那样,一个由英雄组成的小团队还是坚持了下来。C 语言和 UNIX 就是这样的结果。他们并不知道他们的工作会对技术的发展产生多大的影响。

00:00:00 - 发言人 1

我们掀起了新一波的研究浪潮。我们的创造力正在延伸。

00:00:10 - 发言人 2

噪音、噪音。

00:00:13 - 发言人 1

这些人是贝尔电话实验室的设计工程师。

00:00:16 - Saron Yitbarek

在上世纪 60 年代,坐落于新泽西州默里山的贝尔实验室,是科技革新的中心。在那里,我们的未来科技迈出了第一步。在那里,贝尔实验室发明了激光与晶体管,它还是信息论的摇篮。在 1968 年,贝尔实验室的四名程序员创造了一种极具开拓性的工具,它根本地改变了我们世界运行的方式,也标志着贝尔实验室的种种创新达到了新的高峰。

00:00:53

我是 Saron Yitbarek,这里是《代码英雄》—— 一款来自红帽公司的原创播客。在一整季的节目中,我们追寻着编程语言世界中最具影响力的一些故事,现在,我们终于迎来了这一季的结尾。我认为,我们把最好的故事留到了最后。这个故事中的编程语言使本季中提到的其他编程语言成为了可能。在正好 50 年以前,C 语言在贝尔实验室被设计出来,这是一种非常基础的通用程序设计语言。它是如此的基础,以至于我们有时候都会忘记,C 语言的发明是多么意义深远的成就。

00:01:35

为了得到事件的全貌,我们需要回到上世纪 60 年代,正好在 C 语言的诞生之前。那是一个一切似乎都有可能的时代。

00:01:46 - Jon Gertner

在上世纪 60 年代,贝尔实验室简直是研究人员的世外桃源。在今天,已经很难找到与贝尔实验室相似的企业研发实验室了。

00:01:56 - Saron Yitbarek

这是 Jon Gertner,他是《 创意工厂:贝尔实验室与美国革新大时代 The Idea Factory: Bell Labs and the Great Age of American Innovation 》的作者。我们采访了 Jon,让他大家解释当时贝尔实验室的情况。为什么在上世纪 60 年代,贝尔实验室能够成为他所说的“创意工厂”呢?

00:02:15 - Jon Gertner

我想今天我们都相信——“竞争带来伟大的科技革新”,但是我不能确定这种观点的正确性,并且,其实,贝尔实验室的成就在一定程度上是与这种观点相悖的。贝尔实验室的工程师和科学家们并没有特别大的压力,但是与此同时,由于贝尔实验室在诸多的研究实验室中的地位,它又确实可以雇佣到最优秀、最聪明的研究者,并给他们足够的时间去研究感兴趣的问题,同时提供大量的资助。如果你能证明你的研究项目符合这家电话公司(LCTT 译注:指 AT&T)的目标和理念,你就能够得到经费。

00:03:00 - Saron Yitbarek

而 Jon 强调,虽然贝尔实验室是一个商业公司的产物,但它的价值观还是比较接近学术界的。通过让员工自行决定工作方式及内容,贝尔实验室实践了类似于开源社区的开放式领导原则。

00:03:19 - Jon Gertner

这是诸如苹果、谷歌与微软这样的大公司出现前的时代。计算机的历史更多的聚焦在西海岸,聚焦于 自制计算机俱乐部 Homebrew Computer Clum 这样的组织,以及从其中发展而出的企业;但是我认为贝尔实验室和那些企业一样重要。贝尔实验室坐落于一个现在看来几乎不可思议的地方:新泽西的郊区。但是,这里曾聚集了对科技突破做出了巨大贡献的科学家、研究者和计算机工程师,他们的研究成果对全世界都有惊天动地般的显著影响。

00:03:54 - Saron Yitbarek

分时 time-sharing ”就是这些惊天动地的项目之一。它的核心概念很简单,实现难度却极大。他们能构建一个能够同时由成百上千的用户使用的操作系统吗?这样的发明将会使当时的计算机领域为之震动。从 1964 年起,贝尔实验室的天才们,与 通用电气 General Electric 和麻省理工学院(MIT)合作,试图集体推进这项工作的进展。实际上,麻省理工学院在一年前已经有了相关的研究项目,即 MAC 计划 Project MAC ;但是现在,所有这些顶级团队已经团结起来,开始着手钻研大型主机分时操作系统的构建方式。

00:04:40

实际上早在 1959 年, 约翰·麦卡锡 John McCarthy 就提出了分时操作系统的概念。请收听我们 第七集 的节目获知更多细节。他设想了一种可以在多个用户之间切换其“注意力”的大型计算机。麦卡锡认定,这样的一种机器有潜力极大地拓展现有的计算机文化。让我们来设想一下吧,如果一千名用户能够同时在一台机器上工作,你就完成了对整个编程与计算机世界的民主化。现在,这支群星荟萃的团队准备着手将麦卡锡的梦想变成现实,并为他们想象中的操作系统起了一个名字 —— Multics(LCTT 译注:Multi- 前缀代表“多人的”)。

00:05:23

Multics 团队为分时操作系统进行了多年的工作,但是该项目遇到了严重的资金困难,并且在十年之后,项目仍然看不到尽头。雪上加霜的是,项目的领导者 Bill Baker 是一个化学家,对贝尔实验室的计算机科学部门并不感兴趣。除此之外,我们仍然能找到一个新的问题 —— 自尊心问题。

00:05:46 - Jon Gertner

在贝尔实验室,人们每天习以为常的一件事情就是独自工作。我的意思是,贝尔实验室的人们有一种感觉:他们认为自己拥有一切他们所需要的的人才和构思,并且拥有最先进的科技,当他们遇到值得解决的问题时,他们有能力去解决这样的问题。这种看法可能有一定合理性;但是 Multics 项目在贝尔实验室没有进展,在某种程度上也可能是因为像这样更加复杂的、合作性的工作在贝尔实验室的体系中运转不良,也不能让那里的高管们满意。

00:06:20 - Saron Yitbarek

Jon Gertner 是 《创意工厂》 The Idea Factory 一书的作者,他刚刚发表的新书是 《世界尽头的冰》 The Ice at the End of the World

00:06:32

贝尔实验室于 1969 年四月正式宣布放弃 Multics 项目,但这是否就是故事的结尾呢?就贝尔实验室而言,分时操作系统 Multics 之梦已经破灭。但是这个梦真的结束了吗?结果却并不是这样,并非所有贝尔实验室的研究人员都放弃了分时操作系统。四个顽固的拒不退让者在所有人都已放弃之后,继续坚持这一梦想,而那就是下一个故事了。

00:07:08

说实话,有些梦想太美好了,这样的梦想是很难被人抛弃的。

00:07:12 - Joy Lisi Rankin

这是一件大事业。

00:07:14 - Saron Yitbarek

这位是 Joy Lisi Rankin,她是 《美国计算机人物史》 A People's History of Computing in the United States 一书的作者。Joy 将会和我聊聊分时操作系统的理想,以及为什么分时操作系统如此不可或缺。

00:07:27 - Joy Lisi Rankin

开发分时操作系统是一件重要且极富雄心壮志的事,直到该项目开始之前,大部分上世纪 60 年代早期的分时系统在一台主机上都约有 40 至 50 个终端。因此,提升终端的数量是重要性很高的一件事,贝尔实验室的雄心很可能超出了大部分人的认知,这也是这个项目在实现最初目的的过程中碰到了不少困难的原因。但是,尽管如此,分时操作系统继续以不同的形态发展,并真正地走向繁荣;分时操作系统不仅仅在麻省理工学院得到发展,也走向了其他的地方。

00:08:09 - Saron Yitbarek

是啊。那么,当我们谈起上世纪 60 年代,是谁在推动分时操作系统的需求?你提到了麻省理工学院、通用电气公司和贝尔实验室。那么我们的关注点是商业还是学术团体?谁才是真正的推动者?

00:08:23 - Joy Lisi Rankin

我认为学术团体和商业团体共同推动了发展的进程,除此以外,一些 科学 scientific 团体也参与了这项事业,因为,正如我之前所说,分时操作系统是一种更加一对一、富有互动性的计算体验。但是从另一个角度来看,我也会说教育工作者也同样在推动这件事的发展。并且,从国家的层面上讲,当时也在进行关于创建全国性计算设施的对话。那么,基本上来说,所谓的全国性计算设施指的就是全国性的分时操作系统网络。真的,美国的思想领袖们也有这样的言论,他们认为这样的系统会是与供电、电话、供水一样的基础性服务。

00:09:08 - Saron Yitbarek

哇哦。

00:09:08 - Joy Lisi Rankin

对啊,我知道的!这确实很……

00:09:09 - Saron Yitbarek

那可真是一项大事业。

00:09:11 - Joy Lisi Rankin

那是一项非常大的事业。

00:09:13 - Saron Yitbarek

Joy 让我想起了一件事。尽管这一期节目主要聚焦于创造了 C 语言和 UNIX 操作系统的团队,但是在贝尔实验室之外,对分时操作系统的推动是一项运动,比任何一个团队都大。将计算机视为公共设施是一个非常有意义的想法,在这项事业中,有许多优秀的人物,可惜我们不能请他们来到这里,比如 Bob Albrecht 和 Martin Greenberger ,以及其他的一些杰出人物。

00:09:37

好的,在进行了一些预先说明之后,让我继续和 Joy 的对话吧。

00:09:41 - Joy Lisi Rankin

那么,当约翰·麦卡锡在麻省理工大学的演讲上首次公开的谈论分时操作系统时,他明确的将其与电力进行了比较,并说:“这是一个让所有人都能使用计算机的方式,不仅仅是在学校里和商业活动中,还在每个人的家里。”回首过去,再阅读当时的文章与档案,许多人都确信,未来会出现一种能够被规范化管理的计算公共设施。因此,人们对这种全国性的分时基础设施充满了信心和支持。

00:10:22 - Saron Yitbarek

非常有趣的一点是,在 1970 年,IBM 实际上已经退出了分时操作系统这一产业。即使是通用电气也出售了他们的大型主机部门,不过他们还仍然保留了一部分分时操作系统相关的业务。让我们简单地谈一谈这些吧,1970 年发生了什么?

00:10:39 - Joy Lisi Rankin

我认为 1970 年已经一定程度上已经成为某种标志,这也许是人为假想的标志,这一年标志着公共计算设施与分时操作系统产业的失败。从某些角度上来说,这种观点是错误的。我认为在上世纪 60 年代末期,麻省理工和 Multics 项目明显在创建一个支持上千个终端的分时操作系统上遇到了困难,而这是一个知名度极高、影响力很大的项目。在同一时期,数十个基于分时计算模型的商业项目在美国兴起并繁荣发展。这是一个科技泡沫。随后,对于分时操作系统的热情走向衰落。这不完全是因为通用电气出售了他们的计算主机业务,他们在上世纪 70 年代至 80 年代间一直保留着他们的分时计算业务,并且这一业务盈利状况良好。除此以外,当时的大学,例如麻省理工学院,也继续运行着他们的分时操作系统,直到上世纪 80 年代。

00:11:52

因此,依我之见,“分时系统只是一个在上世纪 70 年代破碎的科技泡沫”的公共记忆之所以产生,一定程度上是因为人们过多地关注了 Multics 的困境。然而,事实上来说,如果我们回到过去,看一看当时的人们如何使用分时操作系统,以及分时操作系统赢得了多少利润,了解一下分时操作系统的成功,我们就会发现,其实上世纪 70 年代正是分时系统繁荣的年代。

00:12:17 - Saron Yitbarek

现在让我们把眼光放回到贝尔实验室,由四位技术专家组成的小组想要创造他们自己的分时操作系统。他们是 肯·汤普逊 Ken Thompson 丹尼斯·里奇 Dennis Ritchie 道格拉斯·麦克劳伊 Doug McIlroy 约瑟夫·欧桑纳 J.F. Ossanna 。不过他们并不想完成 Multics,他们想要越级跳过 Multics,制作一个不受过往拖累、功能更为强大的操作系统,他们称之为 UNIX(LCTT 译注:Uni- 这个前缀代表“单一的”)。

00:12:39 - Joy Lisi Rankin

我认为 Multics 是 UNIX 的灵感来源,其原因在于,许多在 Multics 上工作的程序员是如此享受分时操作系统在编程上的优点,以至于在 Multics 陷入困境时,他们便想要创造一个属于他们自己的分时环境。这些来自贝尔实验室的程序员,他们决定构建他们自己的编程框架与分时操作系统,这就是 UNIX 的起源。

00:13:20 - Saron Yitbarek

Joy Lisi Rankin 是 《美国计算机人物史》 A People's History of Computing in the United States 一书的作者。

00:13:29

丹尼斯·里奇 Dennis Ritchie 将自己和其他三名同事称为一个 团队 fellowship 。他们几个开发者想要作为一个紧密的四人小团体而工作,并且他们需要一种能够协调他们程序设计的硬件。但是贝尔实验室已经放弃了分时操作系统的梦想,即便它是一个学术研究的世外桃源,给已经放弃的项目拨款这件事也超出了他们的底线。因此他们拒绝了使用新硬件的提议。为此事购买新的硬件太过昂贵了,为什么要冒险呢?但研究员们还是坚持了下来。

00:14:05

汤普逊和里奇要求得到一种类似 GE645 的机器,这是他们一直用来进行 Multics 相关工作的型号。当他们得知无法得到经费时,他们刚刚在纸上潦草地写下一些关于文件系统的想法。最后,他们在一个他们称之为“太空旅行”的游戏中成功地实现了他们的一些想法,这个游戏运行在 PDP7 机型上,这种机型基本上与 Commodore 64 是同一个级别的。没有贝尔实验室的支持,他们的开发是缓慢的,至少开始是这样的,是一个字节、一个字节地前进的。这四人组复活了分时操作系统之梦,以他们称之为 UNIX 的形式。

00:14:47

不过这里就是问题所在了:UNIX 操作系统是用汇编语言写成的。也就是说,他们用纸带向 PDP7 传输文件;你可以想象到,他们在缺乏理想的工具与上级的支持的情况下,努力构建这个开创性的操作系统时所遇到的困难。UNIX 已经获得生命,但还没有一种合适的编程语言能够让它歌唱。

00:15:23

开发者们初次尝试为 UNIX 设计的语言称为 B 语言,由 肯·汤普逊 Ken Thompson 编写。

00:15:30 - Andy Tanenbaum

这是 BCPL( 基础综合编程语言 Basic Combined Programming Language )的一种衍生语言。

00:15:33 - Saron Yitbarek

这位是 安德鲁·塔能鲍姆 Andy Tanenbaum 。他是阿姆斯特丹的一位计算机科学教授,也是许多书籍的作者,包括经典教材 《计算机网络》 Computer Networks 。让我们听听他讲解汤普逊的 B 语言背后的故事。

00:15:48 - Saron Yitbarek

所以说, B 语言是 BCPL 的一种衍生物?

00:15:51 - Andy Tanenbaum

BCPL 源于一种构建 CPL 编译器的企图,这种语言编写的编译器确实能够起到作用,而 CPL 基于 ALGOL 60,ALGOL 60 语言又源于 ALGOL 58。ALGOL 58 则源于对 Fortran 进行改进的尝试。

00:16:01 - Saron Yitbarek

搞明白了吗?现在的问题就是,B 语言有许多历史包袱。B 语言和它的这些前身相比,并没有太多的突破性改变,因此,B 语言不能完成让 UNIX 歌唱的挑战。B 语言中没有变量类型,对于初学者来说这是一个问题。除此以外,B 语言对应的汇编代码仍然比 B 语言编译器的 线程代码 threaded-code 技术 [1] 要快。

00:16:31 - Andy Tanenbaum

BCPL 和 B 语言只有一种数据类型,就是 双字节类型 word 。双字节类型在基于双字节类型开发的 IBM 的 704 和 709、7090、7094 机型上效果不错,但是从 360 和其它所有的小型电脑开始的机型都是基于 单字节类型 byte 的。在这种情况下,双字节类型就不是一个好主意了,它和现代计算机的匹配程度极其糟糕。因此,显然 B 语言无法解决现有的问题。

00:16:57 - Saron Yitbarek

那么,该团队之前工作使用过的所有机器都是基于双字节类型的,但是在基于单字节对象的操作上,这种类型的机器就不够好用了。幸运的是,在这个时间点上,贝尔实验室的领导们又回来加入了 UNIX 项目,他们意识到了这个团队中正在产生令人激动的进展。他们资助了一台价值 65000 美元的 PDP-11,并且这台机器不是基于双字节类型的,而是面向单字节的。现在,装备上了 PDP-11,丹尼斯·里奇能够在处理编程语言的难题时更进一步。

00:17:36 - Andy Tanenbaum

丹尼斯,以及在肯的少量帮助下,决定编写一种更加结构化新编程语言,包含其它数据类型,比如说 字符类型 char 整数类型 int 长整数类型 long 等等。

00:17:47 - Saron Yitbarek

因此,在 1971 年至 1973 年之间, 丹尼斯·里奇 Dennis Ritchie 一直在调整 B 语言。他增加了一种字符类型,并且构建了一个新的编译器,这样就不需要再使用线程代码技术了。两年结束时,B 语言已经变成了一种崭新的语言,这就是 C 语言。

00:18:08

C 语言是一种功能强大的语言,结合了高级功能和底层特性,能够让使用者直接进行操作系统编程。它的一切都是如此的恰到好处。C 语言从机器层次中进行了足够的抽象,以至于它也可以移植到其他的机型。它并非一种只能用来写写应用的语言。它几乎是一种通用的编程工具,无论是在个人电脑还是超级计算机上都十分有效,而这一点极其重要,因为个人电脑革命当时已经近在眼前。

00:18:49

团队的成员们在确定了 C 语言就是正确的道路之后,就立刻用它重写了 UNIX 内核和许多 UNIX 组件。因此,只要你想使用 UNIX,你就必须使用 C 语言。C 语言的成功与 UNIX 的成功紧密的结合在了一起。

00:19:06 - Andy Tanenbaum

C 语言的流行,其实主要不是因为它是一门比 B 语言更优秀的语言 —— 当然它确实比 B 语言优秀 —— 而是因为,它是编写 UNIX 的语言,并且当 UNIX 广泛发行的时候,它自带了一个 C 语言编译器;甚至最后它还配备了两个 C 语言编译器。那么,UNIX 受到了广泛欢迎,每个使用它的人都有了 C 编译器,而且 UNIX 的一切都是由 C 语言写成的。而 C 语言是一种相当不错的语言,它又是与 UNIX 共同出现的,那为什么还要找其他的编程语言呢?

00:19:33 - Saron Yitbarek

从这里开始, C 语言的价值开始显现。

00:19:35 - Andy Tanenbaum

由于 UNIX 是用 C 语言写成的,并且带有一个 C 语言编译器,C 语言与 UNIX 从一开始就在一定程度上互相依赖,因此,它们也共同成长。在一个关键的时间点,C 语言在 UNIX 系统中已经足够流行时,像 Steve Johnson 这样的人开发了可移植的 C 语言编译器,这种编译器可以为其他型号的计算机产生机器码。最终,出现了面向其他操作系统的 C 语言编译器,人们开始用 C 语言编写各种各样的软件 —— 从数据库系统到……天知道什么奇奇怪怪的玩意儿,因为 C 语言在各种环境下都可用,并且十分有效,效率很高。

00:20:07 - Saron Yitbarek

因此,不久以后,人们也开始用 C 语言编写与 UNIX 无关的程序,因为这门语言的优点是显而易见的。Andy 将为我们讲述,C 语言如何完全接管了整个编程世界。

00:20:20 - Andy Tanenbaum

我想说的是,C 语言在正确的时间出现在了正确的地点。在上世纪 70 年代,计算机的普及范围远比现在要小。普通人不会拥有计算机,并且对计算机一无所知,但是在大学和大企业所拥有的计算机中,有许多都使用了 UNIX 操作系统以及随之而来的 C 语言,也就是说,这些大学和大企业都在使用 C 语言。这些大学与大企业发布了大量的软件,也产生了大量的程序员。如果一个企业想招聘一名 C 程序员,发布招聘广告后一定会有人来应聘。如果想招聘一名 B 语言程序员,没人会来面试。

00:20:49 - Saron Yitbarek

在 C 语言的世界中,有许多基础设施 —— 软件、函数库、头文件等,这一切编程工具都构成了一个完美的闭环。

00:20:59 - Andy Tanenbaum

因此,C 语言变得越来越流行。

00:21:02 - Saron Yitbarek

现在,互联网的兴起导致了人们对 C 语言安全性的关注,这些问题在变种中得到了部分解决,比如 C#。有些时候我们会觉得,好像所有的兴奋点都在 Python 或 Go 等新语言上。但是我们希望能在播客中试图做的一件事就是让大家回忆起当下的我们与历史的紧密关联,而 C 语言的影响至今仍然是不可思议的。

00:21:29

C 语言在现代最出名的产物就是 UNIX 的教子 —— Linux,而 Linux 的绝大部分都是用 C 编写的。就连 Linux 项目使用的标准编译器 GCC( GNU 编译器集合 GNU Compiler Collection ),也是用 C 语言写成的。虽然这一点可能不太引人注意,但是今天所有聚集在 Linux 上的开源编程者,都与一种在半个世纪以前的语言相联系,而 C 语言的统治也在年复一年的增强。

00:22:02 - Andy Tanenbaum

以上这些事情的结果就是世界上占支配地位的两种操作系统的诞生。一个是运行在 Linux 操作系统上的安卓,而 Linux 是重写 UNIX 操作系统的产物。而 iOS,本质上来讲是一种 4.4 版的 Berkeley UNIX。因此,安卓和 iOS 从本质上说都是 UNIX。我怀疑几乎所有的服务器都是运行在 UNIX 或 Linux 的某个版本上的。这些服务器在幕后发挥着巨大的作用,并且任何运行 UNIX 的系统都源于 C 语言,为 UNIX 所编写的一切程序都使用了 C 语言。C 语言确实是无处不在的。

00:22:41 - Saron Yitbarek

安德鲁·塔能鲍姆 Andy Tanenbaum 是一名计算机科学教授,他是《计算机网络》一书的作者。说点有趣的题外话吧,他同时也是 MINIX,一个免费、开源版本的 UNIX 的作者,而 MINIX 事实上也是 林纳斯•托瓦兹 Linus Torvalds 开发 Linux 的灵感来源。当然,Andy 使用 C 语言编写 MINIX。

00:23:03 - Saron Yitbarek

今天,C 语言存在于我们生活中的任何一个角落,从火星上的漫游车到台式电脑上的浏览器。它影响了许多我们在本季节目中提到的语言,例如 Go、Javascript 和 Perl。由于 C 语言与 UNIX 密不可分的联系,C 语言很可能是分布最广泛的编程语言。

00:23:28 - 发言人 7

1998 年美国国家科学奖的获得者是——来自朗讯科技公司贝尔实验室的 肯·汤普逊 Kenneth L. Thompson 丹尼斯·里奇 Dennis M. Ritchie 的团队。

00:23:40 - Saron Yitbarek

回望上世纪 60 年代,这四位贝尔实验室的员工—— 肯·汤普逊 Ken Thompson 丹尼斯·里奇 Dennis Ritchie 道格拉斯·麦克劳伊 Doug McIlroy 约瑟夫·欧桑纳 J.F. Ossanna ——他们那时还不得不向上级乞求关注和资助。但是在 1998 年,汤普逊和里奇就收到了美国国家科学奖,这是为了表彰他们在 C 语言和 UNIX 上的工作。他们也共享了一百万美元的图灵奖奖金。历史的眼光是公正的。

00:24:10

在一整季的节目中,我们一直在追寻那些我们最喜爱的编程语言的发展沿革与魅力。无论它们像 C 语言一样搭上了操作系统发展的便车,又或者是像 Go 语言一样在一种新的基础架构上发展,有一件事是永恒不变的:编程语言有它们自己的生命。它们是活着的。它们出生,成长,走向成熟。有时,编程语言也会变老,走向消亡。我们越多的了解这些语言,我们越会发现编程语言是一股重要的力量,它们总是在不断地变化,以切合时代的需要。我们的职责就是意识到这些变化,并且加以回应。我们的语言一直都是构建我们想要的世界的最佳工具。

00:25:00

以上就是我们所有第三季的《代码英雄》节目。我希望大家喜欢收听我们的节目。节目的第四季已经在制作中,即将推出,敬请期待。

00:25:13

《代码英雄》是来自红帽公司的原创播客。

00:25:18

如果你想深入了解 C 语言或者本季节目中我们提到的任何其他编程语言的故事,欢迎访问 redhat.com/commandlineheroes。我是 Saron Yitbarek ,下期之前,编程不止。


  1. 线程代码 threaded-code 技术:一种通过把一系列调用指令转换成一完整的地址表,然后使用恰当的方式调用的技术。线程代码最初被用来减少代码的占用空间,提高代码密度。通俗地讲,这种技术有点类似于在 C 语言中把一系列的 switch-case 语句转化为用函数指针数组实现的形式。 ↩︎

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ,LCTT SIG 是针对特定领域、特定内容的翻译小组,翻译组成员将遵循 LCTT 流程和规范,参与翻译,并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽(Red Hat)发起的 SIG,当前专注任务是《代码英雄》系列播客的脚本汉化,已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献,并领取红帽(Red Hat)和我们联合颁发的专属贡献者证书。


via: https://www.redhat.com/en/command-line-heroes/season-3/the-c-change

作者:Red Hat 选题:bestony 译者:QwQ2000 校对:Northurland, wxy

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