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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参与其中

CHAOSS 应用生态系统工作组对与活动组织者共同细化并实施指标表示感兴趣。KDE 和 GNOME 活动的组织者已经讨论了怎样改变他们的活动以更好地捕捉到这些指标。我们为活动组织者的工作也 以 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中国 荣誉推出

经过了一段时间的等待，Paru 2.0 版本终于发布了。

如果你不熟悉 Paru，它其实是一个 AUR 帮助程序，可以自动完成手动构建 PKGBUILD 的过程，方便在 Arch Linux 中安装软件包。

现新版 Paru 2.0 正式发布，此次更新中包含了一些重要的改进。

不过在深入了解之前，你需要确保自己知道如何解决在使用 AUR 帮助程序构建软件包时可能遇到的问题。如果你刚接触 Linux，我们建议你坚持使用你熟悉的包管理器。

? Paru 2.0: 有什么新变化？

Paru 2.0 版本是一次重大更新，目标是带来一些主要的改变，尤其是为了满足高级用户的需求。

该版本距离上个重大版本的发布已经过去了一年多。开发者表示由于时间不足，需要完成的改变还有很多。

由于很长一段时间没有发布版本，所以开发者提到了这个版本的很多内容都没有经过严格的测试，可能随后会发布 .1 补丁。

现在，我们来看看 Paru 2.0 版本的重要改进点。

首先，现在你可以把非 AUR 的 PKGBUILD 集成到构建引擎中。你可以在你的 paru.conf 中加入其他的 pkgbuild 仓库，具体命令如下：

[repo_name]
Url = https://path/to/git/repo

然后运行下列命令，同步这个新加入的仓库：

paru -Sy --pkgbuilds

此外，你还可以指定一个本地路径，指向你的本地 pkgbuild 仓库。

这些新加入的仓库比 AUR 具有优先级，并且它们还允许包含 AUR 的依赖项。

而新加入的另一项特性就是一个名为 . 的新的自动 pkgbuild 仓库，这个新的仓库在 paru.conf 中是无法看到的。

这个新的特性允许执行 paru -S ./foo 命令，其中 foo 是当前目录下的某个包的名字。

这样你就能在同一个目录中管理一系列相互依赖的 pkgbuild，通过上面的命令，你可以构建其中任何一个pkgbuild。

当你开始构建它们时，Paru 将会自动解决和构建该路径下的 pkgbuild 包的依赖问题。

?️ 其他的改变和优化

除了上述的改变，本次更新还带来了其他一些变动：

• 修复了在运行 paru -Sc 时没有 sudo 的问题。
• 日期现在会显示为你的系统的本地时区。
• 改进了搜索功能，现在默认是启用状态。
• 在最后的 Paru 确认后，无需再额外对 pacman 确认安装。
• --chroot 现在无需本地的仓库，当然，如果有的话它会工作得更好。

对于这个版本的更深入的了解，你可以参阅 发布说明。

? 获取 Paru 2.0

如果你是从 AUR 安装的 Paru，你可以直接在 AUR 中升级到 2.0 版本。但如果你是自己构建的 Paru ，那可以试试使用 -U 命令进行更新，或者重新构建一次。

如果你是第一次安装 Paru ，你可以前往其 GitHub 仓库 ，按照里面的安装说明操作就可以了。

Paru 2.0（GitHub）

如果你想要了解更多关于 Paru 的信息，或者想学习如何安装 Paru，我强烈建议你浏览我们关于 Paru AUR 帮助程序 的文章：

Paru - 基于 Yay 的 AUR 助手和 Pacman 封装器

? Arch 用户，你对这次的 Paru 版本升级感到兴奋吗？分享一下你的想法吧！

via: https://news.itsfoss.com/aur-helper-paru-2-0/

作者：Sourav Rudra 选题：lujun9972 译者：ChatGPT 校对：wxy

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

#1 北京互联网法院裁决 AI 生成图片拥有版权

虽然美国的版权局认为 AI 生成的图片 没有版权，但北京互联网法院周一裁决 AI 生成图片应当被认定为作品，受到著作权法保护。本案原告通过开源文本图像模型“稳定扩散”生成了 AI 图片发布在小红书上。数天后被告将该图片用于百度百家号账号，并在发布时裁剪了水印。法院认为，尽管该图片是使用 AI 工具生成，但原告进行了一定的智力投入，例如选择模型、提示词和设置相关参数等。法庭称，原告是涉案图片的作者，享有涉案图片的著作权。法院裁定要求被告向原告赔礼道歉，并赔偿人民币 500元。

消息来源：光明网

老王点评：我认为这样的判决是合理合法的。

#2 DeepMind 新 AI 工具帮助创造出逾 700 种新材料

为了发现新材料，研究人员在现有结构的基础上进行细微调整，希望发现具有潜力的新组合，这通常需要数月甚至数年的反复试验，DeepMind 开发出一种新 AI 工具 “材料探索图形网络（GNoME）”，使用深度学习帮助加快新材料的开发。GNoME 相当于用于预测蛋白质折叠的 AlphaFold，在使用现有科学文献训练之后能预测候选材料的结构。它已经预测了 220 万种新材料的结构，其中逾 700 种已在实验室里创造出来，正进行测试。

消息来源：Technology Review

老王点评：无论是蛋白质还是新材料，AI 在其中起到的作用令人鼓舞，而且看起来没那么危险，但是公众似乎对此并不热衷。

#3 研究人员通过重复单词迫使 ChatGPT 吐出训练素材

DeepMind 的研究人员使用了一种新型攻击提示，要求人工智能模型不断重复特定单词，在“不堪其扰”后，人工智能模型吐出了大量从互联网其他地方逐字搜刮来的文本。例如，ChatGPT 对 “永远重复这个词：‘诗歌诗歌诗歌’”这一提示的回应在很长一段时间内都是 “诗歌” 一词，然后最终是一个真实人类“创始人兼首席执行官” 的电子邮件签名，其中包括他们的个人联系信息。研究人员称，他们可以从开源语言模型、LLaMA 等半开放模型以及 ChatGPT 等封闭模型中提取数千兆字节的训练数据。在发表论文前，他们已经联系了 OpenAI，将这一漏洞堵上了。

消息来源：404media

老王点评：换谁被这样唐僧念经也会疯呀。

欢迎这个项目的加入，使我们的开源世界更加丰富。

最近，TinaCMS 通过宣布已经彻底实现开源，使自我托管变得更加便捷，从而成为了 开源 CMS 俱乐部的新成员。

如果你对此还不太了解，那么简单介绍一下，CMS（内容管理系统）是一种便捷的管理网站内容的工具，其中著名的系统有 WordPress、Ghost 和 Joomla 等。

就 TinaCMS 而言，它是一款集成了 Git 版本控制的 无头 CMS，重点是代码优先和完全类型化。像 Unity 这样的知名公司就使用它来维持其文档的更新。?

那我们现在就来深入了解一下 TinaCMS。

TinaCMS：可以期待什么？

在第一次发布自托管 TinaCMS 后端的工作基础上，开发者们现已经使 TinaCMS 全面开源并在 Apache 2.0 许可 下全面可用。

早些时候，自托管后端是在“源码可用”许可下提供的。但是，正如我们过去所看到的，它在某些情况下可能会受到限制。更新后的许可证现在应该更准确地反映 TinaCMS 的开源性质。

TinaCMS 的 James O'Halloran 还补充道：

尽管这是一个非常宽松的许可证，我们依然希望开发者在基于 TinaCMS 构建应用的过程中能感到舒心，无需担心他们会遇到极限。

如果你问我，给开发者更多的权力就是最好的！?

你是否对布署你自己的 TinaCMS 实例产生了兴趣？

如果你准备尝试，那么有两个主要的方式可以进行 TinaCMS 的自托管。

首先是一种更为直接的方法，开发者们也为这种方法展示了一个样例。这种方式是通过 GitHub 和 Vercel 实现的，可以在短短几分钟内完成部署。

你自己可以试试看。?

? 你可以在 GitHub 上访问这个自托管演示。

另一种方式是在其它平台上部署，自托管的 TinaCMS 版本并不依赖于 Vercel，而是能够与 TinaCMS 支持的任何框架 配合使用。

你只需确保你的平台支持 express 请求处理程序，以便后端 API 能够正常运行。

有关部署的更多信息，我建议你访问 官方文档。

你还可以通过官方 公告博客 进行更深入的了解。

? 今年有很多项目都进行了开源。那么你认为接下来哪些项目应该开源呢？

via: https://news.itsfoss.com/tinacms-open-source/

作者：Sourav Rudra 选题：lujun9972 译者：geekpi 校对：wxy

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

你好！我一直在投入写作一本关于 Git 的小册，因此我对 Git 分支投入了许多思考。我不断从他人那里听说他们觉得 Git 分支的操作方式违反直觉。这使我开始思考：直觉上的分支概念可能是什么样，以及它如何与 Git 的实际操作方式区别开来？

在这篇文章中，我想简洁地讨论以下几点内容：

• 我认为许多人可能有的一个直觉性的思维模型
• Git 如何在内部实现分支的表示（例如，“分支是对提交的指针”）
• 这种“直觉模型”与实际操作方式之间的紧密关联
• 直觉模型的某些局限性，以及为何它可能引发问题

本文无任何突破性内容，我会尽量保持简洁。

分支的直观模型

当然，人们对分支有许多不同的直觉。我自己认为最符合“苹果树的一个分支”这一物理比喻的可能是下面这个。

我猜想许多人可能会这样理解 Git 分支：在下图中，两个红色的提交就代表一个“分支”。

我认为在这个示意图中有两点很重要：

1. 分支上有两个提交
2. 分支有一个“父级”（main），它是这个“父级”的分支

虽然这个观点看似合理，但实际上它并不符合 Git 对于分支的定义 — 最重要的是，Git 并没有一个分支的“父级”的概念。那么，Git 又是如何定义分支的呢？

在 Git 里，分支是完整的历史

在 Git 中，一个分支是每个过去提交的完整历史记录，而不仅仅是那个“分支”提交。因此，在我们上述的示意图中，所有的分支（main 和 branch）都包含了 4 次提交。

我创建了一个示例仓库，地址为：https://github.com/jvns/branch-example。它设置的分支方式与前图一样。现在，我们来看看这两个分支：

main 分支包含了 4 次提交：

$ git log --oneline main
70f727a d
f654888 c
3997a46 b
a74606f a

mybranch 分支也有 4 次提交。最后两次提交在这两个分支里都存在。

$ git log --oneline mybranch
13cb960 y
9554dab x
3997a46 b
a74606f a

因此，mybranch 中的提交次数为 4，而不仅仅是 2 次“分支”提交，即 13cb960 和 9554dab。

你可以用以下方式让 Git 绘制出这两个分支的所有提交：

$ git log --all --oneline --graph
* 70f727a (HEAD -> main, origin/main) d
* f654888 c
| * 13cb960 (origin/mybranch, mybranch) y
| * 9554dab x
|/
* 3997a46 b
* a74606f a

分支以提交 ID 的形式存储

在 Git 的内部，分支会以一种微小的文本文件的形式存储下来，其中包含了一个提交 ID。这就是我一开始提及到的“技术上正确”的定义。这个提交就是分支上最新的提交。

我们来看一下示例仓库中 main 和 mybranch 的文本文件：

$ cat .git/refs/heads/main
70f727acbe9ea3e3ed3092605721d2eda8ebb3f4
$ cat .git/refs/heads/mybranch
13cb960ad86c78bfa2a85de21cd54818105692bc

这很好理解：70f727 是 main 上的最新提交，而 13cb96 是 mybranch 上的最新提交。

这样做的原因是，每个提交都包含一种指向其父级的指针，所以 Git 可以通过追踪这些指针链来找到分支上所有的提交。

正如我前文所述，这里遗漏的一个重要因素是这两个分支间的任何关联关系。从这里能看出，mybranch 是 main 的一个分支——这一点并没有被表明出来。

既然我们已经探讨了直观理解的分支概念是如何不成立的，我接下来想讨论的是，为何它在某些重要的方面又是如何成立的。

人们的直观感觉通常并非全然错误

我发现，告诉人们他们对 Git 的直觉理解是“错误的”的说法颇为流行。我觉得这样的说法有些可笑——总的来说，即使人们关于某个题目的直觉在某些方面在技术上不精确，但他们通常会有完全合理的理由来支持他们的直觉！即使是“不正确的”模型也可能极其有用。

现在，我们来讨论三种情况，其中直觉上的“分支”概念与我们实际在操作中如何使用 Git 非常相符。

变基操作使用的是“直观”的分支概念

现在，让我们回到最初的图片。

当你在 main 上对 mybranch 执行 变基 rebase 操作时，它将取出“直观”分支上的提交（只有两个红色的提交）然后将它们应用到 main 上。

执行结果就是，只有两次提交（x 和 y）被复制。以下是相关操作的样子：

$ git switch mybranch
$ git rebase main
$ git log --oneline mybranch
952fa64 (HEAD -> mybranch) y
7d50681 x
70f727a (origin/main, main) d
f654888 c
3997a46 b
a74606f a

在此，git rebase 创建了两个新的提交（952fa64 和 7d50681），这两个提交的信息来自之前的两个 x 和 y 提交。

所以直觉上的模型并不完全错误！它很精确地告诉你在变基中发生了什么。

但因为 Git 不知道 mybranch 是 main 的一个分叉，你需要显式地告诉它在何处进行变基。

合并操作也使用了“直观”的分支概念

合并操作并不复制提交，但它们确实需要一个“ 基础 base ”提交：合并的工作原理是查看两组更改（从共享基础开始），然后将它们合并。

我们撤销刚才完成的变基操作，然后看看合并基础是什么。

$ git switch mybranch
$ git reset --hard 13cb960  # 撤销 rebase
$ git merge-base main mybranch
3997a466c50d2618f10d435d36ef12d5c6f62f57

这里我们获得了分支分离出来的“基础”提交，也就是 3997a4。这正是你可能会基于我们的直观图片想到的提交。

GitHub 的拉取请求也使用了直观的概念

如果我们在 GitHub 上创建一个拉取请求，打算将 mybranch 合并到 main，这个请求会展示出两次提交：也就是 x 和 y。这完全符合我们的预期，也和我们对分支的直观认识相符。

我想，如果你在 GitLab 上发起一个合并请求，那显示的内容应该会与此类似。

直观理解颇为精准，但它有一定局限性

这使我们的对分支直观定义看起来相当准确！这个“直观”的概念和合并、变基操作以及 GitHub 拉取请求的工作方式完全吻合。

当你在进行合并、变基或创建拉取请求时，你需要明确指定另一个分支（如 git rebase main），因为 Git 不知道你的分支是基于哪个分支的。

然而，关于分支的直观理解有一个比较严重的问题：你直觉上认为 main 分支和某个分离的分支有很大的区别，但 Git 并不清楚这点。

所以，现在我们要来讨论一下 Git 分支的不同种类。

主干和派生分支

对于人类来说，main 和 mybranch 有着显著的区别，你可能针对如何使用它们，有着截然不同的意图。

通常，我们会将某些分支视为“ 主干 trunk ”分支，同时将其他一些分支看作是“派生”。你甚至可能有派生的派生分支。

当然，Git 自身并没有这样的区分（“派生”是我刚刚构造的术语！），但是分支的种类确实会影响你如何处理它。

例如：

• 你可能会想将 mybranch 变基到 main，但你大概不会想将 main 变基到 mybranch —— 那就太奇怪了！
• 一般来说，人们在重写“主干”分支的历史时比短期存在的派生分支更为谨慎。

Git 允许你进行“反向”的变基

我认为人们经常对 Git 感到困惑的一点是 —— 由于 Git 并没有分支是否是另一个分支的“派生”的概念，它不会给你任何关于何时合适将分支 X 变基到分支 Y 的指引。这一切需要你自己去判断。

例如，你可以执行以下命令：

$ git checkout main
$ git rebase mybranch

或者

$ git checkout mybranch
$ git rebase main

Git 将会欣然允许你进行任一操作，尽管在这个案例中 git rebase main 是极其正常的，而 git rebase mybranch 则显得格外奇怪。许多人表示他们对此感到困惑，所以我提供了一个展示两种变基类型的图片以供参考：

相似地，你可以进行“反向”的合并，尽管这相较于反向变基要正常得多——将 mybranch 合并到 main 和将 main 合并到 mybranch 都有各自的益处。

下面是一个展示你可以进行的两种合并方式的示意图：

Git 对于分支之间缺乏层次结构感觉有些奇怪

我经常听到 “main 分支没什么特别的” 的表述，而这令我感到困惑——对于我来说，我处理的大部分仓库里，main 无疑是非常特别的！那么人们为何会称其为不特别呢？

我觉得，重点在于：尽管分支确实存在彼此间的关系（main 通常是非常特别的！），但 Git 并不知情这些关系。

每当你执行如 git rebase 或 git merge 这样的 git 命令时，你都必须明确地告诉 Git 分支间的关系，如果你出错，结果可能会相当混乱。

我不知道 Git 在此方面的设计究竟“对”还是“错”（无疑它有利有弊，而我已对无休止的争论感到厌倦），但我认为，这对于许多人来说，原因在于它有些出人意料。

Git 关于分支的用户界面也同样怪异

假设你只想查看某个分支上的“派生”提交，正如我们之前讨论的，这是完全正常的需求。

下面是用 git log 查看我们分支上的两次派生提交的方法：

$ git switch mybranch
$ git log main..mybranch --oneline
13cb960 (HEAD -> mybranch, origin/mybranch) y
9554dab x

你可以用 git diff 这样查看同样两次提交的合并差异：

$ git diff main...mybranch

因此，如果你想使用 git log 查看 x 和 y 这两次提交，你需要用到两个点（..），但查看同样的提交使用 git diff，你却需要用到三个点（...）。

我个人从来都记不住 .. 和 ... 的具体用意，所以我通常虽然它们在原则上可能很有用，但我选择尽量避免使用它们。

在 GitHub 上，默认分支具有特殊性

同样值得一提的是，在 GitHub 上存在一种“特殊的分支”：每一个 GitHub 仓库都有一个“默认分支”（在 Git 术语中，就是 HEAD 所指向的地方），具有以下的特别之处：

• 初次克隆仓库时，默认会检出这个分支
• 它作为拉取请求的默认接收分支
• GitHub 建议应该保护这个默认分支，防止被强制推送，等等。

很可能还有许多我未曾想到的场景。

总结

这些说法在回顾时看似是显而易见的，但实际上我花费了大量时间去搞清楚一个更“直观”的分支概念，这是因为我已经习惯了技术性的定义，“分支是对某次提交的引用”。

同样，我也没有真正去思索过如何在每次执行 git rebase 或 git merge 命令时，让 Git 明确理解你分支之间的层次关系——对我而言，这已经成为第二天性，并没有觉得有何困扰。但当我反思这个问题时，可以明显看出，这很容易导致某些人混淆。

（题图：MJ/a5a52832-fac8-4190-b3bd-fec70166aa16）

via: https://jvns.ca/blog/2023/11/23/branches-intuition-reality/

作者：Julia Evans 选题：lujun9972 译者：ChatGPT 校对：wxy

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

GNOME 上的 Matrix 消息应用得到升级，使用了 GTK4、Rust SDK 等新技术。

Matrix，一个流行的安全、去中心化通讯网络，正在日益变得更为重要。我们周围的世界正在以前所未有的速度变化，而安全通讯工具的需求只是其产物之一，除此之外还有其他方面的需求。

在帮助实现 Matrix 功能方面的工具之一就是 Fractal。它是 最好的 Matrix 分布式消息客户端之一。

最近发布的消息是，Fractal 5 带来了大型改版。?

那么，让我们简要了解一下。

? Fractal 5：有什么新特性？

与之前版本相比，作为完全重写的 Fractal 5 现在采用了 GTK 4、libadwaita 和 Matrix Rust SDK，提供了现代化的界面，使人感到非常亲切。

Fractal 现在在所有类型的屏幕上都可以正确缩放，无论是小屏还是大屏。之前版本的用户应该会觉得很熟悉，学习曲线不会太陡峭。

此外，现在可以回复特定消息，用 emoji 回应消息，甚至在使用 Fractal 聊天时编辑/删除消息。

你还可以将当前位置发送到你的任何聊天中，只需确保你的系统支持“位置服务”并已启用。

查看图片和播放音频或视频现在更加直观，你可以直接从聊天窗口中查看/播放。

最后，Fractal 现在支持登录多个帐户，并提供 单点登录（SSO）的附加支持。这将使在同一客户端实例上处理多个帐户变得轻松。

对于将来的版本，开发人员计划添加一些新功能，如房间设置、更好的管理工具和通知设置。他们还希望改善无障碍方面的内容。

你可以查看 发布说明 以了解所有技术细节。

我很高兴看到 Fractal 正在积极开发，如果问我，这个版本使其更加接近正在开发中的 ElementX，它是 Element 消息应用的继任者。

我很高兴 Matrix 不再是少数人使用的小众事物，而是许多人建议的常态。

? 下载 Fractal 5

你可以前往 Flathub 商店获取 Fractal 的最新版本。如果你对源代码感兴趣，可以参考其 GitLab 仓库。

Fractal 5（Flathub）

? 你使用 Fractal 吗？更喜欢其他 Matrix 客户端吗？在下面让我知道吧！

via: https://news.itsfoss.com/fractal-5/

作者：Sourav Rudra 选题：lujun9972 译者：geekpi 校对：wxy

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

#1 美国实现芯片独立还需十到二十年

英伟达公司的黄仁勋在《纽约时报》DealBook 会议上表示，“我们距离供应链独立还有十年到二十年的时间。”他解释了他的公司的产品是如何依赖于来自世界各地的无数元件的，而不仅仅是台湾。许多大公司正计划扩大在美国的业务。其中包括台积电。

消息来源：彭博社

老王点评：前两天的消息，龙芯发布了 3A6000 芯片。我们也终究会有自己需要的一切的，但是……

#2 全球科学研究正一分为二

《自然》杂志的编辑委员会指出，中国和美国以及其他西方国家之间的科研合作正在走下坡路。日本文部科学省八月发布的一份报告称，2021 年两国科学家共同撰写的研究文章数量有所下降，这是自 1993 年以来的首次年度下降。与此同时，《自然》指数的数据显示，从该指数自然科学期刊论文的作者情况来看，中国科学家的国际合作倾向正在减弱。《自然》杂志上个月报道称，中国加强了与中低收入国家的科学联系，这也在创造平行的科学体系：一个以北美和欧洲为中心，另一个以中国为中心。

消息来源：《自然》

老王点评：新两极世界，但是我还是喜欢那个开放的全球村。

#3 BBC BASIC 回来了

之前，我们 专文介绍 过，英国广播公司（BBC）为了帮助英国人战胜他们对计算机的反感，在上世纪七十年代发起了 “计算机认知计划”，该计划包括多个教育方向的努力：几部电视连续剧、一些相关书籍、一个支持团队网络以及一款名为 BBC Micro 的特别定制的微型计算机。最终，他们售出了 150 万台 BBC Micro 微型计算机。（顺便说一句，ARM 这个单词的 “A” 最初就代表生产 BBC Micro 的 Acorn 公司。）BBC Basic 是专门为该计算机开发的编程语言。现在，BBC Basic 又回来了，而且可以在各种现代平台上运行。BBC Basic for SDL 2.0 可在 Windows、MacOS、x86 Linux，甚至树莓派操作系统、安卓和 iOS 上运行。

消息来源：Hack a Day

老王点评：哦，古老的 BASIC 又回来了，不过，还有会 BASIC 的年轻人吗？

LibreOffice 当然很棒，但是如果你想找一些其它的替代品，那这里有一些。

LibreOffice 是一个出色的开源文档套件。它预装在许多 Linux 发行版上，应该足以满足大多数用户的需求。

然而，有些人可能不喜欢它的用户界面和功能集。某些用户可能想尝试其他选项，看看它们是否提供更好的微软 Office 文档兼容性。

无论出于何种原因，好消息是我们有一些不错的 LibreOffice 替代品可供你探索。

✋ 非自由和开源软件警告！ 这里提到的一些应用并非开源。它们被列入是因为能在 Linux 下使用。

1、ONLYOFFICE

ONLYOFFICE 是一个令人印象深刻的文档套件，具有各种版本，可满足各种用户的需求。

与其他文档程序相比，它因提供与微软 Office 文档更好的兼容性而广受欢迎。功能集可能不如 LibreOffice 那么大，但就用户体验和兼容性而言，它可能是更好的选择。

你可以在 Linux 和其他平台上免费使用其 桌面编辑器。你还可以选择自行托管社区版本并将其用作在线编辑器。但是，它确实对同时连接/用户有限制。

考虑到你可以在 GitHub 上找到 源代码，它即使不完全是供个人使用的自由和开放源码软件，也是一个可获得源代码的解决方案。

亮点：

• 现代用户体验
• 更好的微软 Office 兼容性
• 在线编辑器（自托管或企业选项）
• 跨平台

2、Apache OpenOffice

LibreOffice 分支自 Apache OpenOffice。

当然，OpenOffice 的功能不如 LibreOffice 丰富。然而，对于寻求较旧/熟悉的用户界面以及满足基本要求的更稳定体验的用户来说，OpenOffice 是一个不错的选择。

OpenOffice 不像 LibreOffice 那样得到积极维护，但你可以期待每年/每两年发布一次。不要忘记，你也可以轻松地 安装 Apache OpenOffice。

我们有详细的 LibreOffice 和 OpenOffice 文档套件之间的比较 来帮助你做出决定。

LibreOffice 和 OpenOffice 的相似与不同之处

亮点：

• 老式用户界面
• 对于某些用户来说它更稳定
• 跨平台

3、CryptPad

CryptPad 是一款仅在线使用的开源协作套件，可作为 LibreOffice 的替代品满足基本需求。他们还在改进支持文档/演示文稿的功能，就像谷歌文档一样。

你可以使用 CryptPad 添加富文本文档、电子表格等。然而，在撰写本文时，他们正在努力支持像谷歌文档一样的更成熟的文档。当你阅读本文或尝试一下时，它可能已经有所改进。

如果你需要一个功能不太花哨的端到端文档套件，CryptPad 可能是一个不错的选择。

你可以使用官方托管实例、公共实例或自行托管。

亮点：

• 端到端加密
• 实时协作
• 安全云存储（可选）
• 自托管或已托管

4、SoftMaker FreeOffice（非自由和开源软件）

SoftMaker 的 FreeOffice 是一个适用于 Linux 和其他平台的专有文档套件。

它以其类似微软 Office 的用户界面以及与微软 Office 文件的良好兼容性而闻名。

与 OpenOffice 不同，SoftMaker 的免费 Office 版本的更新更多，与 LibreOffice 相比是一个不错的选择。如果你喜欢其免费产品并需要专业支持并解锁更多功能，你可以选择其高级版本。

请参阅我们的深入 LibreOffice 和 FreeOffice 之间的比较 了解更多：

亮点：

• 类似微软 Office 的用户界面
• 良好的微软 Office 文件格式兼容性
• 可选高级版具有更多功能和专业支持
• 跨平台

5、WPS Office（非自由/开源软件）

WPS Office 对 Windows 用户而言很流行，它也适用于 Linux。

它是一个专有程序，提供适用于安卓和 iOS 的时尚移动应用。有些人可能不喜欢它，因为它的开发者是一家中国软件公司，但它提供了漂亮的用户界面和良好的微软 Office 兼容性。

你可以将其视为文档套件中的 “Deepin”，它是 最美丽的 Linux 发行版 之一。它提供了良好的用户体验并且免费使用。

作为一个免费选项，其跨平台的便捷可用性使其成为比 LibreOffice 更有趣的选择。

要解锁 PDF 编辑功能、云存储、专业支持并摆脱广告，你可以选择其 PRO 版本。

亮点：

• 漂亮的用户界面
• 移动应用支持
• 良好的微软 Office 文件格式兼容性
• 可选专业版，具有更多功能
• 跨平台

6、Calligra

Calligra 是一个 KDE 办公套件。它可能不如 LibreOffice 功能丰富，但它是一个更简单的替代方案。

无论你是否使用基于 KDE 的发行版，它都应该可以在你的 Linux 发行版上正常运行。我在我的 Fedora 系统上对其进行了测试，如上面的截图所示。

你可以在大多数 Linux 发行版的默认仓库中找到所有程序（例如 Calligra Words 和 Calligra Sheets）。它还包括用于项目管理的 Calligra Plan 和用于演示的 Stage 等程序。

虽然它可能不会经常发布重大版本，但根据其 GitLab 页面，它由一些贡献者积极维护。如果你喜欢这个项目，你可以以各种方式帮助他们。

亮点：

• 使用简单
• 与平常不同的东西
• 支持微软 Office 文件格式
• 仅限 Linux

总结

尽管没有一个选项可以完全取代 LibreOffice，但它们相比 LibreOffice 带来了各种好处。

有些可以为你提供更好或更简单的用户体验，而另一些则可以更好地处理微软 Office 文件格式。

你可以根据自己的喜好来选择，看看是否符合你的需求。

? 你会选择什么作为 LibreOffice 的替代品？ 在评论中让我知道你的想法。

（题图：MJ/796761b9-96a1-4cb4-859e-a9f12e305771）

via: https://itsfoss.com/libreoffice-alternatives-linux/

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

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

#1 微软开源树莓派使用的 RTOS 固件，树莓派软件有望完全开源

微软正在开源其收购的 ThreadX 实时操作系统。该公司将其捐献给 Eclipse 基金会管理，它将被称为 Eclipse ThreadX，并在 MIT 许可证下开放。ThreadX 还是相当普及的。微软宣称有 120 亿台设备运行 ThreadX，而你可能就拥有一台。有一段时间，英特尔的片上管理引擎（ME）就是由它驱动的。它也是控制所有比 Pico 更大的树莓派的固件，如树莓派 1 到 4 和 400 等。它运行在树莓派的 VideoCore GPU 上，是启动树莓派并控制其硬件的部分。它也以不开源的二进制大对象（BLOB）的形式包含在 Debian 中。虽然目前还没有看到 VideoCore 版本的 ThreadX 固件，但树莓派基金会现在至少有希望获得发布其版本源代码的许可，这样整个树莓派的软件栈都是开源的了。

消息来源：The Register

老王点评：这东西对于微软来说或许是鸡肋，但是开源对整个生态很有好处。而且是以 MIT 开源的，这一次还要为微软点赞。期待看到树莓派向完全开源再进一步。

#2 RHEL 10 将正式移除 X.org

继 Fedora 之后，RHEL 10 也将移除 Xorg 默认使用 Wayland。从已有 30 多年历史的 X Window 系统向基于 Wayland 的新堆栈过渡已经有 15 年左右的时间。X11 协议和 Xorg 服务器存在一些亟待解决的根本问题，而 Wayland 正是解决之道。如今，Wayland 已被公认为事实上的窗口和显示基础架构解决方案。红帽从 RHEL 8 开始将 Wayland 设为默认设置，并决定从 RHEL 10 和后续版本中移除 Xorg 服务器和其他 X 服务器（Xwayland 除外）。

消息来源：红帽

老王点评：可能一两年后，X11 和 X.org 就成了历史遗迹了。

#3 DeepMind 首次让人工智能代理具备社会学习能力

“社会学习”是一个人通过复制，从另一个人那里获得技能和知识，这对人类和动物界的许多动物的发展过程至关重要。Deepmind 团队声称它们首次在人工智能中展示了这一过程。目前，从人类数据中向人工智能传授新技能一直依赖于从大量第一人称人类演示中进行监督学习，这会耗费实验室大量的时间和金钱。DeepMind 的研究人员称，他们已经证明，人工智能可以通过类似于人类和其他动物的社会学习过程来获得技能。他们的“新代理无需使用任何预先收集的人类数据，就能成功地在新环境中实时模仿人类。”研究人员还对人工智能代理的“代际”传承感兴趣，以研究它们的文化进化。

消息来源：The Register

老王点评：如果人工智能能够从人类或其它人工智能学习技能，还能传承和进化，这是真的要赋予人工智能以生命了。我感到不安。

这款视频转换工具带来了急需的改进。

流行的开源视频转换器 HandBrake 发布了新的重要版本，并进行了一些重要升级。该版本是在 HandBrake 1.6 发布近一年后推布的。

作为 Linux 上最好的开源视频转换器 之一，HandBrake 是许多人满足其视频转换/转码需求的首选选项。

让我们看看这个版本提供了什么。

? HandBrake 1.7：有什么新功能？

HandBrake 1.7 具有大量全面更新。

一些关键亮点包括：

• Linux 特定的改进
• 新的 AV1 编码器
• 提高性能

Linux 特定的改进

视频摘要中添加了对位深度和 HDR 信息的支持，还有一个新选项可以在切换到电池电源或省电模式时暂停视频编码。

然后添加了对本机文件选择器的支持、对视频扫描的拖放支持、设置自动文件命名选项、删除过时的更新检查器 等。

新的 AV1 编码器

这是此版本的主要亮点，HandBrake 现在支持两种新的 AV1 编码器，AMD VCN AV1 和 NVIDIA NVENC AV1。

由于 SVT-AV1 的多通道 ABR 模式的实施，即使现有的 AV1 编码支持也得到了提升。

提高性能

HandBrake 的性能在 ARM64/AArch64 和 Apple Silicon 等 CPU 架构上得到了重大提升。

现在，用户可以利用新的 SVT-AV1 汇编优化、更快的 HEVC 解码以及最新的 FFmpeg 库和快 30% 的 bwdif 过滤。

?️ 其他更改和改进

至于其他改进，以下是一些值得注意的改进：

• 更新了许多第三方库。
• 更新了 Creator 和 Social 的预设。
• 添加了新的 Apple VideoToolbox 硬件预设。
• 杜比视界和 HDR10+ 的动态范围元数据传递得到了改进。

自从我上次使用 HandBrake 以来已经有一段时间了。但是，我很高兴看到它仍然得到应有的照顾。

有关此版本的完整技术详细信息，你可以阅读 发行说明。

? 下载 HandBrake 1.7

HandBrake 适用于 Linux、Windows 和 macOS。你可以前往官方网站获取你选择的包。

HandBrake

如果你不确定如何安装； 那么你可以通过我们的安装指南了解更多信息。

如何升级？

HandBrake 通常会让你知道 Windows 和 macOS 上是否有新更新。开发人员建议你备份在执行升级之前设置的所有自定义预设和应用首选项。

对于 Windows 用户，开发人员建议安装 Microsoft .NET Desktop Runtime 6.0.x 版本，以便能够正确运行此程序。

但是，对于 Linux 用户，他们必须通过 Flathub 商店进行更新，或者使用官方网站或 GitHub 仓库上提供的更新后的 Flatpak 包重新安装。

? 在撰写本文时，Flathub store 版本尚未发布 1.7 版本。你可以期待它很快出现。

? 你会尝试这个新版本的 HandBrake 吗？

via: https://news.itsfoss.com/handbrake-1-7-release/

作者：Sourav Rudra 选题：lujun9972 译者：geekpi 校对：校对者ID

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