通过定义目标并创建指标，衡量你的社区活动的成效。

活动是保持开源社区健康的重要组成部分。一个正面的活动体验可以激励当前的贡献者，并吸引新的参与者。但你如何判断自己的活动是否成功呢？

为了维护所涉及社区的健康，我们 CHAOSS （ 社区健康分析开源软件 Community Health Analytics Open Source Software ）的 应用生态系统工作组 已经针对我们的活动考虑了这个问题。CHAOSS 应用生态系统包括一些针对 Linux 平台开发应用的项目。虽然现在主要由 GNOME 和 KDE 社区主导，但并不由它们定义。就当前而言，应用生态系统主要是由志愿者驱动的，他们是围绕自由软件的原则组织起来的。我们在此分享的工作是我们 2020 年 11 月 针对开源活动的成功指标 文章的更新。

我们遵循“目标-问题-指标”的方法论。首先，我们确定个人或组织可能设定的几个目标。然后，我们找出实现这些目标所需要回答的问题。最后，我们对每个问题设计可以提供答案的可量化指标。对于活动组织者，我们设定了四个目标。

目标 1：保留并吸引贡献者

贡献者是任何开源项目或生态的命脉，而活动则是贡献者体验中的核心。它们为吸引新贡献者提供了机会，同时也能够建立和巩固与现有贡献者的关系。活动应着眼于创造一个和谐而积极的氛围，以便与项目、生态和社区建立深远的关系。

我们需要考虑的一个问题是，参加活动的人在社区停留的时长是多久。如果活动的价值在于加强维持贡献者的关系，我们应当有办法去测量这个效果。要回答这个问题，需要对贡献和活动参与的长期数据进行分析。值得庆幸的是，许多项目已经拥有这些历史数据。

另一个问题是，活动参加者在我们的开源项目中扮演的是什么角色。活动通常都很专业化，可能并不能吸引那些想在 非代码角色 中贡献的人，如设计、文档编写和市场营销。如果项目能够跟踪非代码贡献，尽管这通常很有挑战性，你就可以对其与活动参与者名单进行对应。这些信息可以帮助活动组织者策划能吸引更广泛参与者群体的活动。

目标 2：举办有参与度的活动

活动不仅仅是演讲。它们为社区成员集结起来提供了空间。如果成员之间没有进行交流，那么这次活动就失去了其存在的价值。这也反映在所谓的走廊交谈中，即人们在走廊或会议日程安排之外进行的交流。一些会议甚至为那些没有打算参加任何环节，但希望在走廊里与他人交流的人减价售票。我们需要解决的问题是，如何衡量一个活动在推动参与者之间的交流上的成效。

要衡量会议时间的参与度，我们可以计算在问答环节中提出的问题数量。虽然这个指标直接受每个演讲者的影响，但活动组织者可以采取行动来鼓励问答环节的参与度。例如，活动组织者可以使用他们的早晨主题演讲来鼓励所有人通过提问来表示对演讲者的赞赏。

我们也考虑了在走廊交谈中的参与情况。一种衡量方法是观察人们在非会议时间的行为。另一种方法是在活动结束后的调查中询问参与者的非会议时间的体验。

最后，我们考虑了在虚拟空间的参与情况。一种衡量方法是通过计算在社交媒体上使用活动标签或者来源于我们知道正在参加活动的人发出的信息数量。另一种可能性，无论在线还是现场，都可以设置一种表情符，参与者只需单击即可反映对会议环节、主题演讲和整个会议体验的反应。

目标 3：深入了解公司的贡献

企业和其他机构对活动，甚至社区活动的贡献是极其重要的。他们可能提供赞助、派遣员工去帮助组织，或者只是派员工去参加活动。确保公司在他们的贡献中找到价值是很重要的，但我们必须以不排斥社区贡献的方式来做这件事。我们研究了公司对社区活动的期望，以及我们可以通过何种方式的衡量来提高公司的贡献。

有些开源活动被认为比其他活动更具有公司味，所以你可能会问，有多少比例的参与者是被他们的雇主派遣去参加的，而不是作为志愿者参加的。有时，这种差异体现在门票定价上。否则，这是一个可以在注册调查中轻松问到的问题。虽然这些信息很有用，但这并不是一个完美的指标，因为付费的开源贡献者通常会在他们的工作职责之外参加活动。

我们还考虑了几个指标，比如哪些公司参加活动，除了派遣员工（例如，金钱赞助活动），公司在做什么，以及公司是否会重复参与。认识到这一点对培养长期关系很重要。

最后，我们考虑了具有相似范畴的活动的竞争格局。公司在活动上的预算有限。尽管我们喜欢类似的活动，但他们都从同一池子里的潜在赞助商中吸引人。了解哪些其他活动正在寻求赞助可以帮助组织者更好地区分他们自己的活动。

目标 4：关注多元化和技能差距

由全球各地的人们构建和发展起来的国际社区，这些人来自多种多样的背景，是开源项目的一个重要组成部分。这些社区贡献他们的想法，为共同的目标合作，帮助项目扩大和开拓新的方向。

面对面活动对于项目和组织来说是一个独特的机会，可以让他们的贡献者聚集在一起，让他们交流并分享各种多元的经验，进而推动创新，以不同的视角促进增长。这也是一个培养和强化共享文化的机会，重点在于增加多元化和包容性。这些指标应该能衡量活动对于培养这种多元性，以及在社区中填补技能缺口的贡献有多大。

我们首先考虑我们在活动中有哪些技能培训，以及这些培训包含多广泛的技能。技能培训可以包括教程，动手实践的工作坊，黑客马拉松，或者其他很多形式。我们在编码之外的技能上有技能培训吗？有很多对开源项目有价值的技能和角色，比如组织活动所需要的技能。

然后，有助于看看我们在我们的社区内需要哪些技能，而哪些技能又是缺失的。项目领导和参与培训的人通常是获取此类信息的良好来源。通过将我们拥有的技能培训与社区需要的技能进行比较，我们可以更好地设计未来活动的培训项目。

参与其中

CHAOSS 应用生态系统工作组对与活动组织者共同细化并实施指标表示感兴趣。KDE 和 GNOME 活动的组织者已经讨论了怎样改变他们的活动以更好地捕捉到这些指标。我们为活动组织者的工作也 以 PDF 形式提供.pdf)。

CHAOSS 应用生态系统工作组还挑战了定义开源软件应用生态系统内的市场营销和通信功能指标。朝向这个目标的第一步是和 KDE 和 GNOME 扮演这个角色的人们进行的一次对话。这次对话可以在 CHAOSScast Episode #31: Marketing Metrics for OSS Foundations and Projects 中找到。我们将从这次对话中得到的学习经验转化为目标-问题-指标，如上述对活动组织者指标的描述。

在我们对推广和通信团队的工作之后，我们计划解决财务团队、社区经理、发布经理、跨项目协调人和导师的指标。我们的工作才刚刚开始，我们欢迎反馈和新的贡献者。

你被邀请参与 CHAOSS 应用生态系统工作组的工作。你可以在我们的 GitHub 页面 上找到更多的信息。

（题图：MJ/187d7b91-9f02-47a2-a433-ea5adbbe1ac6）

via: https://opensource.com/article/22/9/measure-success-your-open-source-event

作者：Shaun McCance 选题：lkxed 译者：ChatGPT 校对：wxy

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

微软，你在 GitHub 上的行为究竟是何目的？

许多用户对 微软收购 GitHub 这一事实感到失望。当然，这并非用户能阻止的事情。

因此，有些人选择转向 GitLab 或其他 GitHub 替代品，而部分人则决定坚守在 GitHub，不论他们的感受如何。

GitHub 是无数开发者熟悉的地方。无论现在是谁拥有它，这个平台都有它的价值，所以用户仍然根据自己的需求来选择使用它。

不幸的是，自微软加入之后，平台上才有了某些变化，两者之间似乎存在一些关联，而且部分改变让用户觉得不便。被关注起来的这个变化就是 2023 年 6 月实施的。

现在需要登录才能搜索代码

一位 GitHub 用户/贡献者 抱怨 在未登录的情况下无法在公开仓库中搜索代码，这让人非常失望。

? 在 GitHub 上进行全局代码搜索已经需要登录用户操作，这样已经好几年了。现在所讨论的是仓库内搜索的情况。

下面是他的观点：

这真是让人感到恶心，这是对开源运动的亵渎。我必须指出，微软在这里是在滥用开源运动。

我们被告知这是出于安全考虑……但当我可以简单地克隆仓库，使用更专业的工具进行适当的搜索和分析时，那么这样的安全又是为了什么呢？

那么到底是什么原因呢？！你们还没有获得我们足够的数据吗？只是靠每次上厕所就能赚点钱，你们还要追踪我在看哪一行代码？

此外，他解释了在他认为应公开访问的仓库中搜索代码的不便。

我正在老旧的机器上使用，需要在我们自己的仓库中搜索东西，结果却做不到。我其实希望人们能够搜索我们的代码库。

那我该怎么做呢？我试过登录。但是我的密码管理器不在我手边，所以我不得不拿出我的手机。哦！现在我需要 2FA。然后我得回办公室拿我的 Yubi 密钥。旧的笔记本没有 USB-C 端口？好吧，现在我无能为力了。

这个变化不仅没必要，而且对你们自己的客户来说，简直是敌意。猖獗的敌意！

实际上，无法访问本应公开且对“所有人”开放的代码库让人极度不便。

这就是开源代码应该如何访问的，对吗？

Martin Woodward，GitHub 的开发者关系副总裁，对这个反馈简单地表示，这是一段时间以来的一个改变，主要是为了避免机器人。

对 @koepnick 的不便感到抱歉，虽然在很长一段时间里，我们在全仓库范围内的搜索都要求用户登录，但是当我们在 2023 年提升了搜索能力后，我们不得不将这一要求扩大到仓库内（参看 https://github.blog/changelog/2023-06-07-code-search-now-requires-login/)。

主要是确保我们的服务器能够支撑 GitHub 上的开发者负载，并帮助防止服务器被匿名请求等机器人行为压垮。

当然，这是一个大公司的预期回应。不幸的是，这并没有说服为什么要在 GitHub 上做出这样的改变，而其他平台并没有这个限制。

声明说的更多的是“何时实施了此项更改”。

幸运的是，代码搜索团队的一员 试图阐述他们通过限制获得的优势。

太长不看版：该策略可以减少滥用，但并不能阻止所有的机器人。

那么，让我们思考一下，作为科技行业的重要参与者，微软没有足够的基础设施来抵御机器人，而不是通过限制访问代码来做到这一点吗？难道没有其他方式来保护代码免受机器人和其他恶意抓取器的侵袭，而不需要禁用搜索功能吗？

此外，讨论中的一些用户指出，开源代码的全部意义就在于任何人，无论身份是已知还是未知，都应该可以访问。

尽管代码关联到了开源许可证，但是这个限制似乎违反了开源的概念。

微软是正在私下里试图控制 GitHub 上的开源利益吗？ ?

? 也许微软需要重新考虑这个变动，来让事情变得好一些？或者，也许他们可以提供一个比声明中更好的解释？

（题图：MJ/d35ceb65-521d-4313-8e4c-60df0a898455）

via: https://news.itsfoss.com/microsoft-github-open-source-code/

作者：Ankush Das 选题：lujun9972 译者：ChatGPT 校对：wxy

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

并不是，不过 “功能源代码许可证” 却更进一步混淆了开源许可证的界限。

回溯到我们还用打孔卡和磁带载入软件的那时，所有的程序都是 “自由软件” 和 “开源” 的。然而随后专有软件的出现，一切都变了。针对此状况，程序员们反抗并发展出了第一个正式的自由和开源软件的定义。

现如今，不开源的代码甚至成为了罕见的例外。然而，这并未阻止某些误将开源视为一种商业模式，而非开发模式的公司，试图将专有方法和 “开源” 代码相结合。最新的案例就是 Sentry 推出的 “ 功能源代码许可证 Functional Source License ”（FSL）。

沿袭 服务端公共许可证 Server-Side Public License （SSPL）、 公共条款 Common Clause 和 商业源代码许可证 Business Source License 的传统，FSL 表面上似乎重视开源的重要性，却对开源的核心理念进行嘲讽，形容其方式为“享有自由却无需付出努力”。

呵呵。

其实，Sentry 是一个面向开发者的应用代码监控服务，它源于对 Django（一款开源的，高级的 Python 网络框架）的少量代码开发。如今，它仍然主要用开源代码进行开发。不难看出，没有开源，Sentry 啥都不是。

这也同样适用于其他所有使用 “ 源代码可用 source-available ” 或其他半开源许可证的公司。它们都源自于开源公司，然后为了最大化利润，它们将免费获取的代码进行了重新许可，以锁定代码。

正如 开源倡议 Open Source Initiative （OSI）董事会副主席 Thierry Carrez 对我说的，“有些公司通过利用开源代码库作为主体建立了他们的软件，不需要在使用数百个开源软件包作为他们的依赖关系之前就请求许可。他们通过公开承诺遵守开源原则建立了口碑。但在试图追求更大价值的过程中，他们短视地放弃了最初带给他们成功的模式。”说的真对。

例如 Sentry、MariaDB、Redis 和 HashiCorp 这样一些前开源公司，之所以他们能做出这样的举动，可以归功于他们采用了侵犯了权利的 贡献者许可协议 Contributor License Agreements （CLA）。这些协议是一种法律文件，它定义了贡献者为他们的代码在开源项目中被使用所设定的条款。尽管有些 CLA，像 Apache 软件基金会的 CLA 或 Linux 的 开发者原创证书 Developer Certificate of Origin ，只是用来保护他们项目的法律权利。但其他一些，比如 MongoDB 的贡献者协议，却被用来占有你的代码及其版权。通过这样的 CLA，在任何他们喜欢的方式中使用和重新许可你的代码，对于他们来说易如反掌。

SourceHut 的创始人兼首席执行官 Drew Devault 在谈论 Elasticsearch 从开源向“源码可用”转变时表达了他的观点：“Elasticsearch 归其 1,573 名贡献者所有，他们自己保留着版权，并向 Elastic 授予了一个无条件分发他们作品的许可。当 Elastic 决定 Elasticsearch 不再开源时，他们就利用了这个漏洞，这个漏洞实际上一开始就被他们故意安插进去…… Elastic 对 1,573 的贡献者们、以及所有信任、忠诚于他们，给予他们支持的人们翻了脸。”

如今，我们看到企业 Sentry 和之前的案例如出一辙，换汤不换药。公正地讲，Sentry 很长一段时间以来都一直在使用源码可用许可证。在该公司创建并采用 FSL 前，自 2018 年以来就用了 BSL。如果还有人继续向 Sentry 捐献代码，那他们肯定知道自己在做什么。

那么为何还要做一个新许可证呢？Sentry 的开源负责人 Chad Whitacre 这样解释道：“BSL 存在两个显著的弊端。首先，预设的非竞争期为四年，对于软件行业来说，这简直就是个漫长的周期。这可能会让人产生一种感觉，即最后的开源转变只是一种象征性的举措。这几乎可以说是 100 年那么长。对于 Sentry，我们选择将这个期限缩短到三年，但我们也承认，可能连三年都过长了。”

该许可证期满后，这些代码将会使用 Apache 2.0 或者 MIT 许可证。但实际上，这并不像初听起来那么慷慨。根据 FSL，你可以将它的代码用在任何用途 —— “除了竞争性使用的情况下。所谓竞争性使用，指的是利用该软件开发或提供能够与我们的产品或服务竞争的商业产品或服务，不论是该软件本身，还是我们基于该软件提供的任何其他产品或服务，只要我们是在该软件发布之日或之前就已经提供了这类竞争产品或服务。”

换种说法，你可以查看代码，但不能用这些代码运营业务。如需更深入了解，你可以查看该公司的 FSL 版本的 Apache 和 MIT 许可证。就我个人而言，我认为这两个都不算是开源许可证。

Whitacre 进一步说明了，“更严重的缺陷是 BSL 有过多的参数：变更日期、变更许可证，以及额外使用授予。最大的问题在于额外使用授予，它是一项巨大的填空题，意味着每一个 BSL 实质上都是不同的许可证。”

我无法反驳这一观点。每个公司的 BSL 都不一样。同时，这也意味着当客户与使用 BSL 的公司签约时，他们很难确切知道法律上为他们保留了哪些权益。Sentry 希望通过 FSL 让其产品和服务对其客户更具吸引力。

也许这方法行得通。但我赞同 Carrez 所说的：“发布另一种能剥夺开发者在技术选择中的自主权的许可证变体并非新鲜事：他们其实就是要从整个软件生态系统中摧毁开发者的基本自由，从而明确自己对其专有软件及其许可使用权的所有权。这并不是开源：这只是包装在开源幌子下的专有门户。”

（题图：MJ/beb19f23-c230-4a3f-9bb3-210066ad749b）

via: https://www.theregister.com/2023/11/24/opinion_column/

作者：Steven J. Vaughan-Nichols 译者：ChatGPT 校对：wxy

Vojtux 是 Fedora 项目的一部分，它是一款专门为视力障碍者打造的非官方 Linux 发行版。

我五岁时，父亲给我们带来了第一台电脑。那一刻，我就明确了自己的职业追求：计算机领域。从那时起，我就一直和电脑打交道。在高中阶段，我开始尝试黑客活动，以决定自己专注于何种领域，最终我选择了安全工程师作为我的职业。

如今，我已经在红帽的安全合规团队任职软件工程师两年多了，我在捷克进行远程工作。我已经使用 Linux 12 年了，主要是 Arch Linux 和 Fedora，然而我过去也管理过 Debian、Gentoo 和 Ubuntu。

图片说明：这是一张黑白的笑脸 Vojtech 图片，图中有一个红色边框，背景是一架纸飞机。

工作之余，我玩盲人足球，我还参与了许多项目，这些项目都是为了帮助视力障碍者和视力正常人群建立联系。包括我还在一个为视力障碍者举办活动的小型非政府组织（NGO）工作。我还在开发一个叫做 Vojtux 的 Fedora 项目，这也是一个专门为视力障碍者打造的非官方 Linux 发行版。

辅助技术栈

我在使用智能设备时，需要依赖多种辅助技术，其中最主要的一款叫做屏幕阅读器。它是一款能将屏幕上的内容通过语音或盲文传达给视力障碍者的软件（简单来说，它就像我们的眼睛）。它能读并通知我当前正在关注的按钮或页面元素是什么，使得我能够与图形用户界面进行互动。

屏幕阅读器使用语音合成技术，将屏幕上的内容声音化。市面上有众多的语音合成器，有些听起来比别的更自然。我使用的是 Espeak，它听起来没有那么自然，但是它很轻便，运行也很快。此外，它几乎支持所有的语言，包括我正在使用的捷克语。

最后，我使用了一台能以盲文显示一行文字的盲文显示器，尤其在我写代码或者做代码审查的时候，我离不开它。通过触觉自由地从一个代码元素转移到另一个元素，使我能更轻松地把握代码的结构。我还可以使用它的按钮将光标移至我感兴趣的字符或屏幕区域，如果我想的话，我还能使用上面的盲文键盘输入。

我在日常生活中如何应用辅助技术

作为一个视障人士在使用电脑时，有许多事情其实可以借助上述技术轻松完成。以下是我日常经常做的一些事情：

• 我十分喜欢使用文本控制台。一般来说，只要是文字信息，盲人就可以借助屏幕阅读器进行阅读（虽然并非所有情况都适用，但在大多数情况下是可行的）。我通常用控制台进行系统管理、文本编辑以及查阅指导手册和文档。
• 我喜欢浏览网络并与网页进行互动。
• 我使用 VSCode 和 Eclipse 进行代码编写以及代码审查工作。
• 我会发送电子邮件以及进行即时通讯。
• 我可以使用诸如谷歌文档（虽非开源，但在现代办公环境中广为使用）和 LibreOffice 这样的文本处理软件。谷歌文档的开发团队加入了许多键盘快捷键，我可以利用它们在文档中浏览、跳转到标题或者注释里等等。
• 通常来说，我能够播放多媒体内容，但这也取决于应用程序的开发方式，有些媒体播放器在这方面做得更好。

可行，但困扰重重

随着技术的进步，一些任务尽管是可行的，但完成起来却相当困难，我称这类任务为“可行，但困扰重重”。

处理 PDF 文件非常艰难。有时，我不得不采用光学字符识别（OCR）软件将图像转换为文本。例如，我最近需要阅读一份餐厅菜单，他们在他们的网站上提供 PDF 菜单，但它已经被压平，丧失了文字层。在我这里，这显示为一片空白屏幕。我只能通过在智能手机上使用 OCR 应用程序来帮我提取文本。这不仅需要额外的步骤，而且提取的文本翻译并不总是完全准确。

查看和创建演示文稿也可能困难重重。为了解决这个问题，我采用像 Pandoc 这样的软件用 HTML 创建幻灯片，它可以处理 Markdown 并将其转换成幻灯片。我已经使用这种方法好几年了，效果很好。它允许我完全掌控生成的幻灯片，因为 Markdown 就是简单的文本。

通过将其基于声音或文字，可以使视频游戏更易于接入。然而，在 Linux 上玩游戏可以是一大挑战，不仅需要找到能够进行无障碍访问的游戏，而且由于大多数 PC 游戏原生支持 Windows，因此还需要处理一些兼容性问题。

有些网站和界面比其他的难以导航。往往只需要通过正确设置一些属性，这些问题就可以很容易地得到解决。一般来说，大量的网页内容都以图像的形式存在。提高网页内容可访问性的一个快速有效的方法就是确保图像都添加了替代文本，使得屏幕阅读器可以读出来，让无法辨识图像的人们也能了解图像内容。还有另一种经常遇到的情况是遇到没有标签的控件：你知道那里有一个按钮或复选框，但你无法确定它具体的功能。

Vojtux 项目：为了更好的 Linux 可访问性

开发者并不是特意设计出无障碍访问困难的应用程序，问题在于他们通常不清楚如何测试可访问性。由于视障 Linux 用户数量有限，可访问性的测试和反馈往往不足。因此，开发者往往不能生产易于访问的应用，用户也相应较少。这样形成了一个恶性循环。

Vojtux 项目就是希望能处理这个问题。我们希望能建立一个对视障用户更友好的 Fedora 改造版本。我们的目标是吸引更多用户，并鼓励他们发现并报告问题，以便开源社区的开发者可以解决这些问题。

你可能会问为什么要做这个项目？我们需要明确的是，Fedora 在设计上并非就没有可访问性，实际上，它有许多作为包的形式存在的辅助工具。但这些工具不是从一开始就存在，且需要许多细小的配置才能顺利使用，这可能会让初次使用 Fedora 的用户感到困惑。

我们期望 Vojtux 对视障用户而言尽可能友好和可预知。当用户启动立付镜像时，只需出现图形用户界面，屏幕阅读就会立即开始。所有必要的可访问性 环境变量 将会被正确地加载和配置。

Vojtux 还实现了以下功能，例如：

• 配置开机就能使用的辅助性环境变量。
• 图形界面一加载，Orca 屏幕阅读器就会启动。
• 添加了自定义库，该库包含额外的语音合成和打包软件。
• 添加了许多替代键盘快捷键。
• 还有一个特别的脚本可以控制显示器的开关。很多用户根本不需要显示器，关闭它则是一种极好的节能方式！

想要帮忙？这就需要你了

首先，如果你希望为 Vojtux 做贡献（或只是帮助传播），可以在我们的 项目库 查找更多信息。

此外，在团队中与视障人士协作时，可能需要考虑应用哪些无障碍技术。例如，因为我们都是通过声音获取信息，所以我们很难同时进行听说和阅读，除非有人非常熟练于使用盲文显示器。

最后，要记住，无论是演示幻灯片、网站还是 PDF，盲人和视障用户都与你使用相同的最终产品。当你开发产品或创作内容时，你的选择对我们能否有效地进行互动和访问有着巨大的影响。知道我们在这里，我们热爱使用计算机和科技，并且我们经常愿意帮助你进行测试。

图片说明：手持足球的 Vojtech，他身穿足球服，戴着防护眼镜。

本文作者最初于 2022 年 9 月发布文章，并在后续将项目的官方名称更新为 Vojtux。

（题图：MJ/06477e84-6119-45d0-8085-5936a607ee68）

via: https://opensource.com/article/22/9/linux-visually-impaired-users

作者：Vojtech Polasek 选题：lkxed 译者：ChatGPT 校对：wxy

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

这项技术已经成为全球标准的局域网。

美国加利福尼亚州的施乐 帕洛阿尔托研究中心 Palo Alto Research Center （PARC）创新无数，诞生了诸如 阿尔托计算机 Alto Computer （最早采用图形用户界面的个人电脑）及首台激光打印机等多项开创性计算机技术。

同时，PARC 也因发明 以太网 Ethernet 技术而闻名，这项技术允许高速数据通过同轴电缆进行传输。以太网已经成为全球标准的有线局域网，并在企业和家庭中得到广泛应用。值得一提的是，以太网在诞生五十年后的今年，它被授予了 IEEE 里程碑 IEEE Milestone 称号。

连接 PARC 的 Alto 计算机

以太网的开发始于 1973 年。当时，Charles P. Thacker 在设计阿尔托计算机，他设想了一个网络，能让阿尔托计算机与激光打印机、PARC 的 ARPANET 网关，以及其他阿尔托计算机进行通信。于是，PARC 的研究员、IEEE 会士 Robert M. Metcalfe 接下了这项技术挑战。不久后，计算机科学家 David Boggs 也加入到了 Metcalfe 的团队中。

对 Metcalfe 和 Boggs 来说，他们有两个目标：一是网络必须足够快，以支持他们的激光打印机；二是网络必须能在同一栋建筑内连接数百台计算机。

以太网的设计灵感来源于 夏威夷大学 的 加入链路在线夏威夷地区网络 Additive Links On-line Hawaii Area network （ALOHAnet），这是一种基于无线电的系统。计算机一旦有信息需要发送，就会立即通过一个共享通道进行传输，这个数据包的前栏会注明接收者的地址。若两个信息包发生冲突，发送的计算机会暂停一段随机的时间间隔后重试。

Metcalfe 在一封现在已 广为人知的备忘录 中，向同事们提出了他的提案，早期的时候它被称为“ 阿尔托 Aloha 网络 Alto Aloha Network ”。他提出，使用同轴电缆而不是无线电波可以让数据传输更快，并减少干扰。电缆的使用也意味着，用户可以在不关闭整个系统的情况下，随时加入或退出网络。Metcalfe 在 2004 年接受 IEEE 历史中心 IEEE History Center 的 口述历史 访谈时如是说。

Metcalfe 说:“有一种名为有线电视 压接器 tap 的设备，可以在不割断同轴电缆的情况下，接入电缆信号。因此，[Boggs 和我]选择了同轴电缆作为我们的通信手段。在这封备忘录之中，我描述了以太网的运作原理——它是非常分布式的，没有中心控制，只是一个单一的‘ 以太 Ether ’片段。”

1973 年，Metcalfe 和 Boggs 设计了今日我们所说的以太网的最初版本。它最初的传输速率达到了 2.94 Mbps，“速度足够快，可以供给激光打印机，而且容易通过同轴电缆发送，”Metcalfe 对 IEEE 历史中心说。

一根粗细为 9.5 毫米、质地坚硬的同轴电缆被铺设在 PARC 大楼的走廊中央。这条长达 500 米的电缆上，通过所谓的 “ 吸血鬼压接 Vampire Tap ”（即 N 连接器 N connector ）连接了 100 个收发信节点。这些压接有一个坚硬外壳，它们通过两个类似探针的器件“咬”穿电缆的外绝缘体，接触到了电缆的铜芯。这么一来，在不影响现有连接活跃状态的情况下，就可以增加新的节点。

每个 “吸血鬼压接” 内部都装配了一个 D 型连接器插口，由配对的九个插脚和九个插槽的插头插座组成。这些插座使得阿尔托算机、打印机以及文件服务器能连接到网络上。

为了让这些设备进行交流，Metcalfe 和 Boggs 创建了最早的高速 网络接口卡 network interface card （NIC） —— 这是一块插在计算机主板上的电路板。它包含了现在我们所说的以太网端口。

为了让人们更加清楚地理解，这个系统可以支持任何电脑，研究人员将最初的名字，“ 阿尔托 Aloha 网络 Alto Aloha Network ”，更改为了 “ 以太网 Ethernet ”。这个新名字反映了 Thacker 早期的一种观点，他说，同轴电缆其实就是“被困的以太”。PARC 的研究员 Alan Kay 曾 回忆 起这一点。

Metcalfe、Boggs、Thacker 以及 Butler W. Lampson 在 1978 年因他们的发明获得了美国专利。

他们继续完善这项技术，并终于在 1980 年，PARC 推出了速度为 10 Mb/s 的以太网。根据这份 IEEE 里程碑奖项的描述，这一更新是与英特尔和 数字设备公司 Digital Equipment Corp. （DEC）的研究员共同进行的，旨在为全行业创造出一种通用的以太网版本。

接纳为 IEEE 标准

以太网自 1980 年开始商业化后，其快速地演化成为整个行业的局域网标准。为了向计算机公司提供相关技术的框架，IEEE 802 局域网标准委员会 在 1983 年 6 月将以太网正式定为标准。

目前，IEEE 802 系列已经包含了 67 项已发布的标准，并且还有 49 个项目正在进行中。该委员会和全球各地的标准机构合作，将部分 IEEE 802 标准发布为国际指导准则。

在 PARC 设施外，有一块表彰这项技术的铭牌。其内容如下：

以太网有线局域网起源于 1973 年的施乐帕洛阿尔托研究中心 （PARC），其灵感源自于 ALOHAnet 数据包无线电网络和 ARPANET。施乐、DEC 和英特尔在 1980 年一起发布了一项针对通过同轴电缆的 10 Mbps 以太网的规范，这就成为了 IEEE 802.3-1985 标准。随后该标准进行了增强，提供了更高的速度，支持双绞线、光纤和无线媒介后，以太网在全球的家庭、商业、工业和学术环境中几乎无处不在。

由 IEEE 历史中心管理并得到 捐赠者支持 的 IEEE 里程碑项目，专门表彰全球各地的杰出技术进步。

IEEE 圣塔克拉拉谷分部 赞助了这项提名。该捐赠仪式将于 5 月 18 日在 PARC 设施举行。

（题图：MJ/55dfc9c2-7aaa-447b-9897-8dbb49cdfbcf）

via: https://spectrum.ieee.org/ethernet-ieee-milestone

作者：JOANNA GOODRICH 译者：ChatGPT 校对：wxy

当然，如果你真的关注性能，市面上自然有更出色的选择。

今年是 TOP500 公开排名全球最快超级计算机 30 周年。

为纪念这个重要的里程碑，也因应科罗拉多州正在举行的年度超级计算大会，我们想弄个有趣但稍显愚蠢的实验：看看以今天技术，我们能以多低的成本重现 1993 年超级计算机十强的性能。于是，我们在云上运行了几台虚拟机，并对 HPLinpack 基准进行了编译测试。这里简单透露一下：我们这项实验的结果，你可能并不会太震惊。

到 1993 年年末，最快的超级计算机是日本国家航空实验室的富士通数值风洞。这台装备了 140 个 CPU 核心的系统，能够实现 124 GigaFLOPS 的双精度（FP64）计算能力。

如今，我们的系统已经 突破 了 exaFLOPS 的难关，然而在 1993 年 11 月，如何在功率最高的十个系统中占据一席之地呢？只要你的 FP64 性能超过了美国 CM-5/544 机型的 15.1 GigaFLOPS。因此，我们设定的目标是让云虚拟机超过 15 GigaFLOPS 的性能。

在我们分析结果之前，有几点值得一提。如果我们选用了支持 GPU 的实例，我们知道我们能够达到更高的性能。不过，云端的 GPU 实例租赁并不便宜，并且在 2000 年年中至年底，GPU 才真正开始广泛出现在 TOP500 的超级计算机中。此外，在 CPU 上运行 Linpack 比在 GPU 上运行要容易得多。

这些测试只是为了纪念 30 周年，只是稍微有点新颖，决不具有科学严谨或详尽无遗的特征。

一台 5 美元的云虚拟机对比一部 30 年前的 TOP500 超级计算机

但在开始测试前，我们需要开启一对 VPC。在本次测试中，我们选择在 Vultr 上运行 Linpack，但其实在 AWS，Google Cloud，Azure，Digital Ocean 或者是你喜欢的任何云服务商上，这都同样适用。

首先，我们启动了一个月费 5 美元的虚拟机实例，它具备了一个共享的 vCPU，1GB 的内存和 25GB 的存储。准备就绪后，我们便启动了 Linpack 的编译。

在这，事情可能会有些复杂，因为我们实际上可以对系统进行一些调优，挤出一些额外的 FLOPS。然而，考虑到这只是一个测试，也为了尽可能保持简单，我们选择了依照 这个指南 进行操作。此份操作手册是基于 Ubuntu 18.04 编写的，但是我们发现在 20.04 LTS 上运行也一切正常。

为了产生我们的 HPL.dat 文件，我们利用了一个巧妙的 表单，它会自动产生一个优化版的 Linpack 运行配置。

我们对几种不同类型的虚拟机进行了三次基准测试，并从每次运行中挑选出最高的得分。以下就是我们的发现：

从我们的测试结果可以看出，一个单一的共享 vCPU 在与 1993 年 11 月十大超级计算机的比较中表现出颇为出色的性能。

我们通过一个 CPU 线程就获得了 31.21 GigaFLOPS 的 FP64 性能，这使得我们的虚拟机与 1993 年排名第三的超级计算机 —— 明尼苏达超级计算中心的 30.4 GigaFLOPS CM-5/554 Thinking Machines 系统相提并论。这确实令人吃惊，因为那台系统拥有 544 个 SuperSPARC 处理器，而我们的系统只有一个 CPU 线程，虽然我们的系统运行在更高的时钟速度下。

如你从上面的图表中所见，每月多花 1 美元，我们的性能跃升至 51.85 GigaFLOPS，而选择一个价值 18 美元的“高级”共享 CPU 实例，双线程使我们进一步接近 87.46 GigaFLOPS 的性能。

然而，要超过 富士通的数值风洞，我们需要升级到四个 vCPU 的虚拟机，由此我们抓取到了 133 GigaFLOPS 的 FP64 性能。然而不幸的是，升级到四个线程的费用跳到了每月 48 美元。达到这个价格，Vultr 实际上是在销售部分 GPU，我们预计如果采用 GPU，性能应会有显著提升，效率也会更高。

更好的选择

我们需要明确的是，这些都是我们选择的共享类型实例。一般来说，共享实例意味着在一定程度上进行了超额配置。

由于共享实例可能会受到其他租户的影响，这也使得性能有时难以预知，甚至每次运行的性能都可能略有不同，这主要取决于云区域中主机系统的载荷状态。

在我们的非常不科学的测试中，我们并未观察到太多的性能变化。我们想这可能是因为核心并未处在过高的负载下。在专有 CPU 实例上进行同样的测试，结果与我们每月 6 美元的共享实例相若，但成本高达五倍。

但是，除了这场小实验的新奇趣味之外，这没太多实际意义。如果你需要在短时间内获得大量 FLOPS，有许多已优化的 CPU 和 GPU 实例可供选择。它们的成本无法与每月 5 美元的实例相媲美，然而大多数实例是按小时账单的，因此实际成本将取决于你完成工作的迅速程度。

此外，让我们不要忘记，你的智能手机与这些存在已久的 30 年老计算系统相比，又会有怎样的对比呢？

（题图：MJ/16cf957e-a4e4-43b1-99b2-df0574a064dc）

via: https://www.theregister.com/2023/11/14/five_dollar_supercomputer/

作者：Tobias Mann 译者：ChatGPT 校对：wxy