Blog

sourcehut， 一个反叛而又正统的代码托管平台

The hacker's forge

Posted by UlyC on August 10, 2022

sourcehut， 一个反叛而又传统的代码托管平台

一. Feature

  • 绝对没有跟踪或广告
  • 许多功能无需账户即可使用
  • 最快和最轻的软件仓库
  • 100%的自由开源软件（FOSS）

好吧，以上是sourcehut官网列出的Feature ，好像听起来也就那样？

但是我要说，如果用一句话来评价sourcehut的话，应该是：

sourcehut融合了黑客的核心智慧和雅致的 Web 界面。

如果不想看我废话，直接体验的地址 点击

是的，古典得像是上个世纪的UI， 点进项目主页也看不到熟悉的 issue/PR/fork/start。

有点像是换皮的Gitweb 或者 CGit，不过它远没有这么简单。

二. 真正的Feature

我无意对他们官网进行机翻， 这里说下他们吸引我的地方吧：

  • 简洁的Web UI
  • 模块化
  • 古典而反潮流的工作流
  • 强大的持续集成

1. 简洁的Web UI

其实我开始就是被他们的UI风格吸引而入的坑，太有那个味儿了。

2. 模块化

非常经典的Unix设计哲学，“Do one thing and do it well”。

整个平台由许多单独的服务组成，高度模块化，每个服务只做一件事，做好一件事，所有模块可以自由组合，按需使用。

例如 git.sr.ht 就只做 Git 的代码托管， todo.sr.ht 就只做 issue 和 bug的追踪，而账号管理又是meta.sr.ht模块来做。

关于更详细的各个模块的介绍可以看下面的 各模块介绍 。

3. 古典而反潮流的工作流

这就是sourcehut最具争议，而也是 sourcehut之所以为sourcehut的一点：

彻底抛弃 Pull/Request 的工作流，而回归最古老的去中心化方式————邮件列表（Email-List）。

很多人一提到开源项目工作流，可能首先想到的就是PR模型，对于邮件列表的形式维护代码比较陌生。

首先PR并不是Git本身的一种功能，然后他的历史并不久远，毕竟2008年 Github才正式上线。

而 上世纪80 年代中期，Richard Stallman 就发起了 自由软件运动(Free Software Movement)，邮件列表那时就被广泛使用。

很多 Git 项目，包括 Git 本身，以及很多古老的大型项目，都是通过邮件列表来维护的。

邮件列表有以下一些显而易见的优点： - 邮件列表会将更新转发给所有列表订阅者，任何人都可以轻松地将它们变成另一个公共存档，独立于 sourcehut。 - 这样的存档也可用于以标准文件格式一键导出和导入列表管理员。使用 DKIM 和 PGP 签名等，您甚至可以跨任意来源保持这些消息的真实性。 - 不依赖一个中心化的代码仓库

在如今这个时代，拥抱邮件列表，完全不用PR，无疑是反叛的，同时也具有一种对古典传统方式的卫道者精神。

当然有很多人质疑，认为这会阻碍 sourcehut的发展，以及扩大用户群体。对此，sourcehut创始人 Drew DeVault 这么认为：

-  我们更愿意教人们如何使用强大的工具，而不是制作更容易使用的不太强大的工具。我不相信用户没有能力学习新事物。
-  我没有最大化 sourcehut 的可能用户群。我正在为那些认为这些原则值得的人构建一个体现我的开发原则的平台。
-  (相对于邮件列表)PR模型并不容易使用，您只是已经知道如何使用它
-  sourcehut无意成为Github的另一个模仿者(Clone)
-  对，它(sourcehut)不是革命性的

如果你对邮件列表这种形式比较感兴趣，这里有一些教程和资源：

4. 强大的持续集成CI

  • 在各种Linux发行版和BSD上运行完全虚拟化的构建
  • 提交临时Job，而不需要推送到你的版本库中
  • 为电子邮件、webhooks等提供构建后触发器
  • 构建失败后可以用SSH登录以进一步调查

很多知名项目，比如 Zig, Nim, NeoVim 等都单独使用它的CI模块。 是的，如前所述，你可以不用sourcehut托管代码而单独使用它的任意模块。

5. 官网Feature的一些注解

最快和最轻的软件仓库

  • 这是他们完 全 客 观的， 和Gitea Gitlab等的性能对比。

绝对没有跟踪或广告

  • 可以做到0 JS，不搜集用户隐私
    • 想想Gitlab， 如果禁用了JS根本就不能用
  • 试试如果挂着Tor，哪些平台能工作得很好
  • 就算被Gov施压，也不会突然删除你的代码，而会给你留出充分的时间备份，并向你道歉（
  • 也绝不会扫你的公开或私人仓库投喂人工智能 ，确实是个隐私友好的好Code Forge
  • 官方的Nginx配置:

无需注册账户

  • 使用git-email 的工作流，贡献代码完全不需要注册账户

100%的自由开源软件（FOSS） 以及 付费

所有代码都是自由 和 开源的，你可以自由分发改写使用它们，同时注册免费账号来贡献代码。 不过创建自己的代码仓库和项目，以及其他功能，只对付费用户开放。（不过目前项目仍处于alpha阶段，付款不是强制的，但仍期待您付费

为什么付费？

托管这些服务不是免费的，甚至也不便宜。钱必须来自某处。

大多数其他公司都是由风险资本提供财政支持的，其形式是由少数人的大量投资。如果你免费使用他们的服务，或者即使你为他们的付费计划支付适度的费用，他们也没有动力首先为你的需求服务。他们对投资者负责，在他们的要求下，他们可能实施你不喜欢的变化：侵入性跟踪，出售你的数据，等等。

sourcehut没有接受，也永远不会接受任何外部投资。我们唯一的收入来源是来自sr.ht用户的账户支付。这激励我们只考虑你的需求，而不是将你作为一种资源来利用。这种财务关系对双方都更加负责。

与GitHub和GitLab不同，你的sr.ht订阅费用会留在开源之中。sr.ht是100%的自由软件，大部分在GNU Affero General Public license（又称AGPL 3.0）下许可。我们结合社区的变化，共同建立最好的服务。你的付款提供了运营成本，保持有人在线维护网站，开发新功能，并提供可靠的服务。我们承诺只将我们的利润投资于自由软件或自由文化的努力，事实上我们已经赞助了许多这样的项目。

这是三种订阅套餐， 没有任何区别 （😄， 量力而行。

如果你是学生（打钱，不想付费或者其他原因，可以发邮件联系，他们会慷慨地给你免除费用。

或者可以阅读下面的 自托管指南 ， 自己搭建。

三. 各模块介绍

git.sr.ht 和 hg.sr.ht

这两个服务都是托管代码仓库的服务：

  • 公开的、私人的和 “unlist “的存储库
  • 细致的访问控制，包括对没有账户的用户的访问
  • 还提供一流的Mercurial支持

git.sr.ht 用来托管git， hg.sr.ht用来托管Mercuria（另一个版本控制器

仓库有一个额外的设置，即“unlist”，只有在知道 URL 的情况下才能访问，不会显示在个人页面。

man.sr.ht

一个wiki服务：

  • 使用git进行版本控制和管理你的wiki
  • 使用你喜欢的任何组织层次，扁平化的维基并不强求
  • 支撑 详细的sourcehut手册

todo.sr.ht

一个 issue and bug 追踪服务：

  • 只有可操作的任务 - 没有讨论、问题或重复的任务
  • 安全问题的私人错误报告和错误跟踪器
  • 通过电子邮件参与，无论是否有账户

跟issue不一样的是，这里只应该有明确的，可执行的任务，讨论和反馈应该通过 lists.sr.ht创建专门的讨论区。

lists.sr.ht

提供邮件列表服务，所有的 需要邮件列表实现的功能都是通过它：

  • web 补丁review工具
  • 可搜索的主题邮件档案
  • 与第三方邮件列表合作的工具
  • 由git send-email提供技术支持

builds.sr.ht

前面提到过的持续集成服务。

paste.sr.ht

提供文本文件托管，有点像Bitwarden-send，或者Gist， 支持的功能有：

  • 语法高亮
  • 历史记录
  • Markdown 渲染

meta.sr.ht

是sr.ht的认证中心和提供账户服务。 运行任何其他sr.ht服务的前提条件就是需要安装 meta.sr.ht。

  • 来自每个服务的PGP加密和签名的电子邮件
  • 带有TOTP的双因素认证
  • 帐户活动的详细审计日志
  • 细致的第三方OAuth访问控制

pages.sr.ht

提供静态页面的托管，类似 Cloudfare pages或者Github pages.

chat.sr.ht

为用户维护一个持久的 IRC 连接，并通过离线消息传递、日志持久性和各种其他改进等有用的功能扩展 IRC。

除了接受来自任何第三方 IRC 客户端的连接外，chat.sr.ht 还提供了一个现成的 Web 客户端。

chat.sr.ht，只对付费用户开放。

四. 自托管指南

使用包管理器安装

是官方的安装文档，官方提供了 Alpine Linux、 Arch Linux 和Debian发行版的安装包，也推荐此安装方式。

自己编译

这是他们的官方代码仓库，但是非常不推荐自己编译，因为他们自己人都不得不承认这极其地麻烦。

要跑起来他们代码的化，你最少需要安装Go、python、以及nodejs，以及一堆依赖。 还要注意构建顺序，反正最后我是没成功 🤷🏻。 如果对这种方式感兴趣的话，下面两篇文章可以参考：

Docker安装

当有人问Drew 关于将sourcehut运行在Docker中的事情时，他回复道：

我们这不欢迎你们这类人，不要再问了。

其实使用Docker比较违反sourcehut原本的精神：

你应该愿意理解某些东西是如何工作的，而不是拒绝任何不是即插即用的东西

但是复杂繁琐的配置和环境的安装（还有不完善的文档）可能会吓退很多人，于是 我写了个用Docker运行sourcehut的项目。

简化了很多配置，可以交互式地生成 最终的 配置文件，和DockerCompose文件。

不推荐用在生产环境中，仅推荐感兴趣的人使用它来简单体验。

项目地址：

彩蛋

为什么他们的域名是 sr.ht，而不是src.ht呢? 其实 sourcehut最初的名字叫 sir hat。

参考链接

CATALOG
    FRIENDS
    知识共享许可协议
    本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。