为什么我要将 Dillo 从 GitHub 迁出

GitHub似乎正追随当前过度聚焦大型语言模型和生成式AI的潮流，这些技术正在摧毁开放网络(或其残余部分)，同时引发其他诸多问题

 💬 214 条评论 |  github/开源 | 

我计划将 Dillo 项目从 GitHub 迁移至新平台，该平台将更适配 Dillo 的使用场景并解决其部分问题。本文概述当前 GitHub 平台的现状，并阐述我决定迁移至自建服务器(同时在其他代码托管平台设置多份镜像)的决策依据。

背景说明

在深入细节前，需简要说明旧站点的历史沿革。原始 Dillo 官网位于 dillo.org，其源代码通过 Mercurial 版本控制系统托管于 hg.dillo.org。该站点还包含用于联系开发者的邮件服务器、缺陷追踪系统及邮件列表存档。然而2022年域名失效，新持有者建立了一个充斥AI生成广告的仿制站点。原始开发者已不再活跃，所幸我保留了Mercurial仓库副本，并在协助下从原始服务器恢复了大量资料(至今仍有部分缺失)。

元素周期表

我希望能最大限度避免此类情况，因此不能依赖可能随时崩溃导致项目全盘丢失的单一站点。最初我将Dillo源代码和网站上传至GitHub的Git仓库，但现在认为此举并不妥当。

GitHub现状

GitHub曾有效存储了Dillo项目的所有仓库，并为我无法部署机器的平台(如Windows、Mac OS或某些BSD系统)运行CI工作流。

然而其存在若干缺陷，已不适合作为Dillo的开发平台。最令人困扰的是其前端几乎依赖JavaScript运行——即便问题报告、拉取请求、源代码及CI日志主要采用纯HTML格式，我们仍无法在Dillo浏览器中直接访问这些内容，这种情况实难接受。过去该平台还能在禁用JavaScript时实现优雅降级，如今却已失效。此外，该页面资源消耗极高，而渲染静态文本本不应如此耗费资源。

另一个重大问题在于其单点故障风险。我并非指GitHub存储在单台机器上，而是指其由单一实体掌控——该实体可单方面封禁我们的仓库或账户，届时我们将无法通过该URL通知用户相关变动。若未备份本地数据，此举可能导致数据丢失。

在可用性方面，该平台随时间推移日益迟缓，严重影响开发流程。它还要求用户始终保持高速网络连接，而我时常无法满足此条件。此外，GitHub似乎推崇“推送模式”——当项目发生新事件时主动通知用户，但我更倾向于“拉取模式”，即仅在主动查询时获取更新。这种模式还能方便离线工作。遗憾的是，其他代码托管平台也纷纷效仿了这种推送模式。

在社交层面，我认为其缺乏有效的用户管理工具，尤其在非技术用户占比远高于开发者的项目中。当活跃议题区充斥着从未贡献过代码的用户评论时，这种情况尤为棘手——这些评论往往弊大于利，最终导致开发者精疲力竭。

最后，GitHub似乎正追随当前过度聚焦大型语言模型和生成式AI的潮流，这些技术正在摧毁开放网络(或其残余部分)，同时引发其他诸多问题。这对我们产生直接影响：网站为抵御激进的LLM爬虫机器人导致的负载过载，纷纷筑起JavaScript防护墙(甚至更恶劣的浏览器指纹识别)，却将Dillo用户拒之门外。因此我更倾向于不助长这种趋势。尽管我的初衷如此，但迁移Dillo并不会实质改变他们利用我们的代码训练模型的能力，至少我不会主动助纣为虐。

自建Dillo服务器

经调研现有方案，目前没有任何代码托管平台能支持我们构建冗余系统——既能避免平台成为单点故障，又能解决GitHub的其他问题。因此我决定亲自托管Dillo，将所有关键数据迁移至Git仓库，并在多个Git镜像站点保持同步。

我购买了dillo-browser.org域名并配置了一台小型VPS。最初我对它能否在当今网络环境中生存持怀疑态度，但目前看来它处理得相当不错(主要应对伪装成用户的AI机器人流量)。Dillo官网现可访问：

https://dillo-browser.org/

我调研了哪些Git前端工具可能符合我们的需求，发现多数选项在自托管时操作复杂，且需要大量服务器资源及前端JavaScript支持。最终测试了用C语言编写的cgit，其内存和CPU占用都相当轻量。此外，其网页前端无需JS支持，因此可通过Dillo浏览器使用(我已微调cgit的CSS以适配Dillo)。访问地址如下：

https://git.dillo-browser.org/

关于缺陷追踪器，我也考察了现有方案。这些工具都过于复杂，且倾向于将数据集中存储在数据库中——这种模式极易导致数据丢失。旧版Dillo缺陷追踪器正是如此，至今我们仍无法恢复原始缺陷记录。

为规避此问题，我开发了自制的buggy漏洞追踪工具——这款简易C语言工具能解析纯Markdown文件，为每个漏洞生成独立HTML页面。所有缺陷都存储在Git仓库中，每次提交时Git钩子会自动再生缺陷页面及索引。由于采用纯文本存储，我可在本地编辑缺陷记录，仅在恢复网络连接时推送至远程仓库，因此离线状态下也能顺畅使用。此外，由于输出仅为静态HTML站点，我无需担心代码存在漏洞问题，因为该工具仅在构建时运行。您可在此处查看实时演示(导自GitHub的issue)：

https://bug.dillo-browser.org/

邮件列表存档由三个独立外部服务存储，但未来可能考虑将副本纳入自有存档系统。

镜像站点配置

由于所有关键数据现已存储于Git仓库，我们可在任意代码托管平台创建镜像站点，无需依赖其专有存储格式处理问题记录等数据。若某代码托管平台故障(或恶意篡改)，我们可低成本切换至其他站点。为此，我已在Codeberg和Sourcehut创建与本地Git服务器同步的镜像：

然而我们仍存在单点故障：dillo-browser.org域名的DNS解析记录。若该记录丢失(如dillo.org遭遇的情况)，所有服务都将无法访问。我们可通过邮件列表、联邦宇宙或IRC等替代渠道联系用户，同时更新镜像站点以反映当前状况来应对这种情况。虽然并非理想方案，但由于所有数据现已存储在Git中并跨独立位置进行复制，我认为不会造成灾难性数据丢失(如先前发生的情况)。

OpenPGP签名

为确保本页内容可信度，HTML文件已使用我的GPG密钥进行签名 (密钥ID：32E65EC501A1B6FDF8190D293EE6BA977EB2A253)。该密钥亦用于签署Dillo浏览器的最新版本，并登记于我的GitHub用户页 。该签名可在此处查看，并通过rel=signature关联属性使用<link>标签链接至签名页面。更多信息及签名验证方法详见Dillo RFC-006。

采用OpenPGP签名可有效规避DNS条目丢失风险，因为权威性并非由TLS证书链提供，而是基于对OpenPGP签名的信任——即使网站迁移至其他位置，我们仍能证明其归属权。此外，由于所有Git镜像中均存储签名数据，该方案还具备数据丢失容错能力。

结语

请注意迁移过程涉及多个环节，需要一段时间才能稳定(转换成本)。GitHub仓库在任何阶段都不会被删除，并将持续更新直至迁移完成。迁移结束后，我将把Dillo仓库标记为存档状态，并在官网进行正式公告。为避免影响仍依赖GitHub地址的下游构建流程，切勿删除任何提交记录或tarball版本。

最后，我很高兴我们能够拥有完全独立且自主托管的网站，其运营成本相对较低，能源消耗也微乎其微(这对环境有益，但在大规模运营时可能甚至难以察觉)。考虑到当前的域名解析和服务器费用，加上现有捐赠收入，我认为即使在最坏的情况下，我们仍有能力至少维持未来三年的运营开支。若您希望支持我们持续运营，可通过Liberapay平台提供资助。

本文文字及图片出自 Migrating Dillo from GitHub

共有 214 条讨论

  1. 这几年我一直在折腾GitLab作为自托管替代方案。确实挺喜欢它，但资源消耗实在惊人！

    最近几天我试用了Forgejo(来自Codeberg团队)。体验绝佳。

    最大的区别在于内存占用。GitLab基于Ruby on Rails框架，涉及十余项服务(GitLab本体、nginx、PostgreSQL、Prometheus等)。而Forgejo采用Go语言编写，仅需单一二进制文件即可运行。

    我个人使用GitLab已有数年(仅限个人用途！)，它总会逐渐耗尽16GB虚拟机的全部内存。而Forgejo仅试用数日，在分配的8GB内存中仅占用300MB——这台机器同时运行着服务器和运行器(虽然运行器处于空闲状态…)。

    我对Forgejo充满期待，准备彻底弃用GitLab。目前发现的最大差异是Forgejo暂不支持GraphQL，但REST API初步看来完全可用。

    编辑：我不太理解Gitea和Forgejo的区别。有人能解释吗？通过podman运行时，我看到Forgejo卷内大量目录，明显表明它们在底层实现上有诸多相似之处。

    编辑2： Forgejo似乎是2022年Gitea项目治理出现异常时的软分叉：https://forgejo.org/compare-to-gitea/#why-was-forgejo-create…

    回复

    1. > 我对Forgejo充满期待

      我们产品工作室约50名日常需使用Git的用户，近两年前已迁移至自托管的Forgejo。

      这次迁移带来的积极影响实在难以言喻。Forgejo 作为纯 Go 语言服务的特性使其存储与配置模型极易理解，部署维护成本低廉。团队已贡献多项修复与改进，并围绕 Forgejo 构建了大量内部工具——若使用 GitHub 则需进行复杂(且低效)的集成。

      我们的主实例部署在本地，因此即使在极其罕见的网络中断情况下，开发和持续集成流程也不会受影响(Forgejo同时兼具包管理器的注册库/存储库功能，因此我们还能缓存依赖项和Docker镜像)。

      回复

      1. 等等，Forgejo内置容器注册库？具体如何实现？管理界面完全没看到这个功能。

        回复

        2. 只需运行 podman 或 docker login your.forgejo.instance.address，然后按常规方式推送即可。需确保存在现有仓库。可在站点管理 -> 软件包下查看镜像。

          说到身份验证，它同时兼具 OpenID 提供商功能，意味着你可以将支持该协议的任何其他网络软件认证到 Forgejo… 进而能在其他来源中查找用户。

          还内置维基功能。

          这是款被低估的软件，占用系统资源少得离谱。

          回复

          1. 太棒了！简直难以置信——它不仅支持OCI(Docker)格式，还兼容APK(Alpine)和APT(Debian)包管理器。这功能实在酷毙了。

            回复

      2. “Forgejo同时兼容主流包管理器的仓库/存储功能”

        请问是否支持OpenWRT包？

        回复

        1. 既然支持Alpine，加上OpenWRT近期已切换至出色的Alpine APK包管理器，应该支持。

          回复

    2. 维护便捷性才是更显著的差异。我们使用Gitea已逾五年，此前还用过几年GitLab，相比之下Gitea几乎无需维护。升级只需拉取新版本并重启守护进程，仅需几秒钟。对于希望最大限度减少基础设施维护时间的自建用户而言，这绝对是最佳解决方案。

      备份由zfs快照处理(与其他服务器相同)。

      同期停机时间较github至少降低10倍，且所有停机均为计划内操作，且总在深夜进行。总爱看那些不懂行的人在此宣称github的正常运行时间远超任何自建平台，实在可笑。如今我通常懒得回应了。

      回复

      1. 我想补充一点，虽然GitLab是个庞然大物，但我自建部署已逾十年，几乎从未出过问题。操作其实很简单：安装他们的Omnibus软件包仓库，然后执行apt install gitlab-ce即可。

        回复

      2. 自建GitLab时我从未觉得维护有多麻烦，只需在compose.yml里改个版本号，偶尔遇到连续跳过几个版本时需要在官方推荐版本间切换。

        和许多人一样我也转用了Gitea，但每次访问GitLab时总忍不住感叹它的设计/用户体验实在更胜一筹。

        回复

        1. 我对GitLab的常规印象是：它塞满了大量我永远用不到的功能，导致真正需要的操作(代码、问题、PR、用户权限)反而被无谓地隐藏。请问在哪些工作流程中，您认为GitLab的用户体验优于Gitea？

          回复

          1. 比如刚才退出Gitea实例时就踩坑了——移动端设计把两个一模一样的头像+用户名模块堆叠在一起，一个是组织切换器，另一个是(毫无提示的)菜单栏里的退出按钮。

            进入项目页时，搜索框竟自动获得焦点(???)，导致手机端画面放大。

            我个人更偏好GitLab的设计风格与交互体验，而非Gitea/Forejo。这并非什么惊世之见——GitLab问世更久，生态支持也更完善。

            回复

          2. 我也是这么认为的。它功能庞大，但我不需要所有功能，反而觉得臃肿。之前就切换到Gitea自建代码仓库(防火墙后非公开仓库)，至今未遇问题。

            回复

          3. 你可以将常用功能固定在左侧菜单

            回复

      3. Gitea的界面糟糕到无法使用，我最终转投完整版GitLab。

        Gitea拒绝执行某些完全合理的操作——我认为这与创建自有仓库的分叉有关。查阅资料发现这毫无技术依据，官方解释竟是“GitHub就是这么做的”。当即卸载。这种不尊重用户的态度我无法接受。

        回复

        1. Gitea界面糟糕到无法使用，我已切换至完整版GitLab。

          这是Gitea界面改版前还是之后的情况？1.23版本进行了重大界面重构，后续版本还有更多调整。当前Forejo采用的是Gitea 1.22界面，延续了早期GitHub的设计风格。

          回复

      4. 我发现Gerrit的维护成本也极低。

        若采用高可用性或多站点架构，升级时甚至无需停机。

        回复

      1. Sourcehut的CI任务定义令人愉悦：https://man.sr.ht/builds.sr.ht/manifest.md

        其精妙之处在于：仅需提交YAML文件(通过网页界面、API或命令行)即可触发任务，无需为每次任务推送提交。这对于低频任务或提交前测试CI清单尤为便利。

        回复

      2. 两者都是YAML丛林，我同样厌恶它们。

        回复

    4. 使用GitLab这类平台相比我当前的做法(仅用SSH服务器加文件系统)究竟有何优势？创建新仓库时我这样操作：

        ssh example.com ‘mkdir repos/my-proj.git && cd repos/my-proj.git && git init —bare .’

      然后将远程仓库URL设置为example.com:repos/my-proj.git

      example.com上的文件系统每日自动备份。既然个人项目无需提交拉取请求，又能通过TODO.md管理待办事项和问题，我究竟错过了什么？多年来我一直用 GitHub 处理开源项目和工作，但对于我独自开发的项目，除了 Git 和代码编辑器，我为何还需要额外的 UI？

      回复

      2. 经营餐厅这类场所究竟有什么优势？相比我在家自己做饭呢？

        -> 便利性、协作性、灵活性

        回复

        1. 个人项目无需协作。我觉得我在评论中已经很明确地表达了这个观点。

          回复

      3. 我认为持续集成运行器是GitLab相较于基础Git的主要优势。此外，若你希望向他人展示个人项目，能够提供可通过浏览器查看的文件差异或历史版本链接会很方便。或者直接提供语法高亮文件、渲染后的Markdown/Jupyter文件，以及历史版本的tarball存档。

        回复

      4. 协作功能，特别是与非Git极客的协作。这正是当年GitHub赢得版本控制系统战争的关键。拉取请求机制吸引了所有不愿学习补丁编写和邮件发送的人群。

        回复

        1. 没错，关键在于PR机制。但存在一个误解——因为提问者和回答者的使用场景截然不同。在远程服务器上自建仓库(可能仅与一两位协作者共享)固然简单，但这与运营公开征集贡献的开源项目完全不同。

          回复

        2. 我认为，若连补丁差异文件都无法准备，其作为贡献开发者的能力就值得彻底质疑。

          回复

          1. 没错，通过邮件传递补丁的项目门槛通常远高于接受GitHub PR的项目，但具体采用哪种方式取决于项目特性吧。

            回复

        3. 我特意强调“个人项目”并排除PR，是因为这类项目中我将是唯一的贡献者。

          回复

      5. 我们$DAYJOB公司内部曾部署过git服务器，其配置方式正是楼主所提(git init --bare)。后来操作渐显繁琐，当我发现forgejo时欣喜地发现：导入现有git仓库轻而易举，只需在配置中指向现有git存储根目录，再通过图形界面分配组权限即可。

        回复

      6. 根本不需要！代码托管平台本就用于脱离Git提交节奏的协作。当你每次有问题要补充时，都会乐于创建新提交。若每小时产生X个问题和Y条评论，用讨论内容污染Git时间线反而会适得其反。

        某些托管平台甚至内置即时通讯功能！

        https://secure.phabricator.com/Z1336

        回复

      7. 这就像问“既然有rsync，Dropbox有何用”。rsync固然优秀，但多数人根本不会用。

        回复

        1. 配置SSH+GitLab的服务器比纯SSH服务器更复杂。Dropbox确实优秀，我也在使用，但仅因rsync无法在不增加大量协调工作的情况下实现同等功能。但若我独自开发个人项目，何必为自己的代码额外配置一个只读界面？

          回复

          1. 若独自工作，你甚至可以选择用电报键发送原始IP数据包。闭门独处时做什么本就是个人自由。但对其他人而言，GitLab的价值在于：配置完成后，不同技能水平和背景的用户都能通过它协作。

            回复

            1. 正因如此我才询问个人项目采用这种架构有何益处。你目前的回答最不具参考价值。

              回复

    5. 若追求极致精简，Gerrit作为Java应用本身不依赖数据库等外部组件，所有配置与运行时信息均存储于文件系统中——主要以数据结构形式保存在Git仓库里。

      只需共享文件系统即可实现扩展/复制，备份流程也因此变得极其简单。

      回复

      1. 我可能是少数对此感兴趣的人之一——虽然它是Java开发的，但看起来确实很酷。它是否像gitea、GitHub那样管理Git仓库？还是更偏向仓库的项目管理平台？描述中提到“代码审查”，所以不太确定。

        虽然谷歌关联让我有些顾虑，但它似乎能相当独立地运行。

        回复

        1. 它必然需要托管Git服务器(使用jgit实现)，但核心功能是代码审查工具。

          即便是浏览其托管的Git仓库，也依赖另一工具的嵌入式版本(gitiles)。

          https://gerrithub.io/是其公开实例

          回复

        2. 它高度专注于代码审查和持续集成(CI)功能，表现极为出色。

          该平台不侧重代码仓库常见的其他功能(如美观展示README文件、任意页面托管、维基、缺陷追踪等)，但可轻松集成第三方实现方案。

          回复

        3. > 虽然谷歌关联让我有些顾虑，但它似乎能相当独立地运行。

          是的，这确实是个非常健康的开源项目，谷歌通常贡献约40%的代码，但还有其他公司如GerritForge(声明：我在这里工作)、英伟达、SAP、高通、维基媒体基金会等都在大力贡献。

          回复

      2. 部署过程或许简单，但与此同时，Gerrit的代码审查工作流实在糟糕。

        回复

        2. 就个人体验而言，Gerrit采用的基于rebase和堆叠提交的集成方式，比GitHub的PR更简洁高效。

          在两者都进行过CI集成的实践中，Gerrit的API通过单一通道发送合并前后的事件通知，而GitHub则需要多个独立监听器。

          回复

    6. 我们也在考察Forgejo。您是否有Forgejo Actions的使用经验可以分享？这正是我们略感忐忑的环节。

      回复

      1. 我昨天配置了Actions。虽然存在些许小瑕疵，但对我而言运行良好。我用它构建Hugo博客，该博客通过Svelte应用实现“sprinklylls”功能，因此需要同时运行Node.js+Hugo，并配合用Zig编写的自定义协调器。

        具体操作：

          * 使用自有注册域的自定义Docker镜像，内含Hugo/Node.js及自定义Zig应用
    * 运行无碍
  * 存储构建产物
    * 需使用不同版本的“uses”指令(v3而非v4)：uses: actions/upload-artifact@v3
    * 此处体现了GitHub Actions与GitLab CI的细微差异，但个人认为这是进步——毕竟GitLab CI的YAML格式完全不同
    * 无法像GitLab那样浏览构建产物，仅支持下载zip压缩包 虽非大问题，但能避免下载文件夹杂乱更佳
* 无法使用“forgejo-runner exec”命令——该命令常用于推送前验证工作流正确性
    * 出现异常错误：“Error: Open(/home/runner/.cache/actcache/bolt.db): timeout”
    * 推测GitLab近期也破坏了此功能！
  * 让运行器配合podman并作为服务运行颇费周折(现已解决)
    * 主要问题在于podman默认不创建docker套接字
    * 且运行器配置文件内的docker_host路径存在差异
    * 存在两个配置文件：一个(JSON格式)始终存储在.runner目录下，包含认证信息和IP地址；另一个是YAML格式，需通过-c参数指定，用于配置runner运行参数(如docker选项等)。个人认为同时存在两个配置文件的设计略显奇怪。
        回复

        1. > * 异常错误：“Error: Open(/home/runner/.cache/actcache/bolt.db): timeout”

          当运行 `forgejo-runner daemon` 时尝试使用 `exec` 命令会触发此错误——两者同时尝试打开缓存数据库，仅首次打开者可正常操作。可通过修改配置文件中的cache.dir来变更守护进程的缓存目录，或让两个进程以不同用户身份运行来规避此问题。

          > 我认为存在两个文件有点奇怪。

          .runner文件并非配置文件，而是状态文件——不建议用户自行编辑。不过确实有点奇怪。

          回复

        1. 你们在构建MacOS应用吗？更具体地说，是否在CI环境中完成代码签名、公证和打章？若如此，相关操作是否已形成文档？我在GitLab上实现这些功能时遇到了巨大困难。虽然最终成功了，但始终在寻找替代方案。

          回复

    7. 这篇文章引发了一个担忧——单点故障问题。没错，这种情况下，微软这种大公司嘛(我并非反对，但…)。比起雷德蒙德那头巨兽，我更担心Paypal/Google等平台封禁风险。

      自建服务器依然存在单点故障问题，而文章提倡的“镜像方案”嘛…读取操作能实现冗余，但写入呢？

      这确实是对纯粹主义问题的有趣探讨。

      回复

      1. 我认为这是个合理的担忧，例如forgejo本质上只是磁盘上的一个简单目录，可选项是将其转化为S3存储。根据线程模型和经验，通过不同程度的“高级”配置来实现所需的弹性，这确实是显而易见的解决方案。方程式中缺少FAANG/M巨头更使其令人欣慰。

        回复

      2. Dillo项目面临的挑战在于源代码读取的冗余性。数年前域名注册失效后，冒名者迅速抢注导致官方仓库离线。若非用户保留了仓库副本，源代码及历史记录本将永久消失。

        如何在不依赖权威机构(如GitHub账户或域名)的情况下，确保用户能识别出在线项目的真实性？这始终是个缺乏完美解决方案的难题。所幸如今项目已重获新生，且比以往更具韧性。

        回复

      3. 我认为禁用评论的做法很奇怪。不过，平台对他们变得不可用其实只需政策调整(我认为微软更可能这么做)或底层软件变更(微软同样可能实施)。请记住，Dillo浏览器是为那些无法或不愿适应现代网络现实的人而生的。

        回复

    8. 而Gitea最初也是从Gogs分叉而来，当时引发了不少争议。

      如今Gitea项目已具备更多功能，如持续集成和单点登录。若你仅需一个类似2010年代初GitHub风格的Git服务器界面——且硬件资源受限——Gogs仍是可行的替代方案。

      回复

    9. 我多年管理过众多本地部署的GitLab实例，从搭建到定制都亲力亲为。GitLab根本不存在内存泄漏问题，这是无中生有的说法。它的资源消耗完全取决于你配置的资源规模，这点远胜于JIRA等工具。

      这条评论让我怀疑整个讨论串是为其他产品造势的虚假宣传。

      回复

    10. 真希望GitLab能像Jira那样支持类似SQL的查询语法，不过它的界面确实更胜一筹——尽管对我来说依然过于“繁杂”。

      回复

  2. > 为解决此问题，我开发了自己的缺陷追踪工具buggy——这是个极其简单的C语言工具，能解析纯Markdown文件，并为每个缺陷生成独立HTML页面。

    黑客精神永存。

    回复

    1. 这种做法鲜有人尝试。我绝不会这么做，因为它带来的麻烦远大于潜在收益。

      回复

      1. 没关系。不是每个人都能成为顶尖C开发者。

        回复

    2. 专程来评论这个，简直令人惊叹，看起来如此简洁利落。

      回复

    3. 2025年不该再有人写C语言软件了…

      回复

  3. GitHub似乎鼓励“推送模式”——当项目发生新事件时主动通知用户，但我不想采用这种模式。我更倾向“拉取模式”，只在主动查询时获取更新。

    我认同这种想法，但想指出：通过邮件通知也能实现推拉转换——只需将相关邮件自动过滤到专用文件夹，你便可自主决定何时查看。

    回复

    1. 若此方案仍不理想，GitHub本身也提供独立的通知界面模块。

      这纯属无中生有。

      回复

  4. >前端在无JavaScript环境下几乎无法运行…过去它能优雅降级运行，如今却强制依赖JavaScript。

    GitHub前端开发者确实知晓这些无障碍问题(通过论坛和错误报告)，只是他们不再关心。他们只追求网站初始加载时的表面正常——这就是为什么首页采用纯HTML文本呈现，而其他页面却并非如此。

    回复

    1. 我非常想了解GitHub将核心产品功能迁移至React的幕后故事。

      这显然标志着公司内部一场剧烈的文化变革。十多年来，GitHub一直是我心目中加载迅捷且无需依赖JavaScript的成熟应用典范。

      如今的新React系统即便在顶级配置电脑上运行也迟缓不堪。

      我推测当初做出技术决策的“元老派”已全部离职，而自2020年前后起，几乎不可能招聘到非JavaScript/React优先的前端工程师，行业潮流的压力终究难以抗拒。

      当然也可能是我误判了——或许他们经过GitHub元老们的严谨论证，并基于坚实的技术依据，做出了全面拥抱重型JavaScript功能的技术决策。

      GitHub过去向来对内部技术决策保持高度透明。真希望他们能公开阐述这次转型背后的故事。

      回复

      1. 针对我关于深度决策的自问自答，我刚发现这篇由GitHub七年的老将Joel Hawksley在2025年2月发表的演讲： https://hawksley.org/2025/02/10/lessons-from-5-years-of-ui-a…

        相关引述：

        > 但除了可访问性和可用性之外，人们对GitHub越来越期待它能具备更强的应用程序特性。

        > 首个案例是当我们重构GitHub项目时。客户要求的功能远超我们现有功能集。更广泛地说，我们看到同领域其他公司正通过更具应用程序特性的体验进行创新。

        > 这促使我们采用React框架。虽然暂无计划用React重写GitHub核心，但我们正用React构建多数新功能——尤其那些应用化场景。

        > 这一决策实施两年间，我们新增约250个React路由，覆盖了用户每周平均访问页面的一半。

        随后文章阐述了移动端已成为新基准，GitHub需要打造更接近移动应用的界面体验。

        (个人认为基于JavaScript的React代码在移动端是灾难，因为在主流(安卓)设备上加载速度极慢。不过GitHub的核心用户群可能更倾向于使用高性能手机？)

        回复

        1. 反观 gitea/forgejo，他们极力减少 JavaScript 使用，过去一年多一直在移除前端库。例如弃用 jQuery 转而采用原生 ES6+。

          让他们在“应用级体验”里窒息吧。若条件允许，请立即切换至其中任一平台。我已连续五年在生产环境中每日使用，强烈推荐。

          回复

        2. 我真心认为相关人员很可能本就因各种原因想转向React/SPAs，只是在寻找借口——所以才给出这些模糊且看似不成比例的理由。移动优先胜过桌面？应用化体验凌驾于性能之上？

          非技术因素主导技术决策的情况，比我们愿意承认的更为普遍。

          回复

        3. 这场演讲最荒谬之处在于：过去五六年间GitHub前端代码量从约20万行暴增至200多万行。代码量增长十倍…速度却变慢了？

          回复

          1. 这也意味着团队规模大幅扩大，性能优化审查的空间更大——在企业环境中堪称绝佳成果。人们终究会追随激励机制。

            回复

        4. 谁真在手机上用过GitHub？
          真想看看他们的相关日志。

          回复

            1. 这样做能实现什么？

              优化对象似乎太小众了。

              回复

                  1. 是啊，每天能花一小时遛狗，看看当地的鹈鹕，同时还能在手机上搞些有趣的项目，这生活真是悲哀。

                    回复

                    1. 说你的人生就是边遛狗边在手机上提交PR，这可不是你想象中那么酷炫的事。

                    2. 这些都是我个人项目的PR。我享受爱好。

                      批评别人的爱好，可没你想的那么酷炫。

                    3. 这两条评论都不该得到回复。直接举报走人。

                    4. 各位尽情享受自己的爱好吧，船长。

        5. GitHub是写代码的工具：该用在台式机上

          没人关心GitHub的移动端体验

          微软又在重蹈Windows 8的覆辙

          回复

            1. 是啊，我敢打赌用平板操作Windows 8的人也只有三个人。

              回复

              1. 我觉得你严重低估了人们用手机操作GitHub的普遍性。

                仅就接收新问题和PR通知而言，这就是我的操作场景。我怀疑不止我这样。

                回复

                1. 我觉得你属于极少数派，不过我们确实无从知晓。

                  回复

        6. “类似应用”到底是什么意思？这明明是网站不是应用。难道他们没有手机原生应用吗？

          回复

      2. > 我的猜测是当初做出技术决策的“元老派”都离开了，而自2020年前后起，几乎不可能再招聘到非JavaScript/React优先的前端工程师，最终行业潮流的压力变得难以抗拒。

        我衷心希望不是这样，但恐怕你说的没错。

        我(理论上)是个iPhone应用开发者，对响应式编程范式实在深恶痛绝：我能理解其理论优势，但实践中那层神奇的粘合剂从未真正奏效，反而带来痛苦的性能代价。React之于我，正如大型语言模型之于怀疑论者。

        尽管如此，我仍因LLM技术及其对UI的吞噬能力而重新学习，但尚未确定下一步方向。

        回复

      3. 速度太快反而让人停留时间短。故意拖慢节奏反而能获得更亮眼的数据分析。

        回复

      1. 这种“服务器端渲染”的议题框架实则是一步前进两步后退——观察微软GitHub的实际操作便知。他们会因无障碍问题暂时在网页启用文本功能，数月后却在该类页面乃至更多场景中移除。正如我参与的讨论串所揭示的，这场战役注定失败。微软GitHub终将彻底沦为纯JavaScript应用。个人用户应当考虑迁移个人项目。至于工作项目嘛，为了钱往往不得不做些令人作呕且违背道德的事——而GitHub正是金钱聚集之地。

        回复

    3. 公平地说，开发者或许在意，但高层管理绝对不在乎——而他们才是决定开发者能否支付本月房租的人。

      回复

    4. 修复无障碍问题不会让股东满意，但强行向我们灌输人工智能却能。

      回复

    5. 根据WCAG标准，必须启用JavaScript才能浏览网站并不算无障碍问题。

      回复

      1. 若你使用的是不支持JavaScript的Dillo浏览器，这绝对是真实存在的无障碍障碍。

        回复

        1. 若你试图用树枝和石头访问互联网，那同样是真实存在的无障碍问题

          回复

          1. 这取决于浏览器的运行环境，因此相当相关。

            回复

          2. 渲染文本和按钮为何需要JavaScript？难道在万物JavaScript化之前，浏览器就无法实现这些功能吗？

            回复

            1. 今年恰逢JS成为网络标准组件的30周年。渲染文本按钮确实不需要它，但如今我们对互联网的运用方式已截然不同。

              回复

            2. 这就像你需要用大型语言模型来编程一样。

              回复

              1. 你在HN上每条评论都是复制粘贴吗？还是专为我准备的？

                回复

      2. “启用JavaScript”和“强制使用仅三款浏览器支持的前沿功能JavaScript虚拟机”是两回事。

        回复

  5. 此外，GitHub似乎在推广“推送模式”——当项目发生新事件时主动通知用户。但我不想采用这种模式，更倾向于“拉取模式”，即仅在主动查询时获取更新。这种模式还能轻松实现离线工作。遗憾的是，我发现其他代码托管平台也复制了这种推送模式。

    能否有人好心解释一下？推送模式和拉取模式有何区别？推送模式为何难以支持离线工作？

    回复

    1. 据我所知，作者希望采用Source Hut和Linux内核的工作方式：通过电子邮件协作。

      使用邮件协作时，需将相关IMAP邮箱同步到本地，从而获取所有提议的补丁——这便是拉取模式。

      随后可离线处理提议的变更，在本地副本中操作后，将合并后的变更推送回线上。

      回复

      1. 我期待更多项目采用git-bug，它在离线协作方面表现出色。所有缺陷追踪信息都存储在仓库本身。https://github.com/git-bug/git-bug

        虽然它仍需完善才能匹配大多数代码托管平台的功能，但对于小型封闭团队已足够高效。

        回复

      2. 需注意POP和IMAP是协议层面的实现，没有任何规定要求代码托管平台(或其他网站)必须通过标准IMAP端口向用户提供内部消息/通知系统服务；用户完全无需额外搭建中继桥接器，将外发消息转发至Fastmail/Runbox/Proton等第三方邮箱。您只需允许用户将IMAP客户端指向_您的_服务器，通过用户名密码认证，即可通过该方式获取通知内容。您无需实现通常与电子邮件(接收消息)相关的服务器间联合机制，也无需担心外发邮件的投递可靠性。

        回复

      3. 这些解释都很合理。感谢说明。不过我似乎仍不明白其中的区别。

        他们把“GitHub拉取请求”工作流称为推送模型？但这哪里涉及“推送”了？我明明可以把所有拉取请求补丁下载到本地离线处理，不是吗？

        回复

        1. GitHub拉取请求会推送通知/邮件让你处理合并操作，而你必须主要在线处理拉取请求。

          我不清楚如何将拉取请求下载为补丁包离线操作，但你必须创建分支、将PR合并到该分支、测试内容，最后将分支合并到相关主分支。

          或者你需要下载分叉的仓库，通过测试验证变更是否相关/稳定，若无问题再合并PR。

          —

          编辑：似乎可以获取PR的补丁或差异文件，操作虽简单，但仍需联网才能获取。因此仅从邮箱收取邮件远远不够，你必须通过工具或手动获取所有PR的差异文件，并进行整理。相比之下，邮件处理方式统一且简便得多。

          —

          无论哪种方式，离线状态下都无法审查变更内容，且当项目热门时，PR的提醒通知会造成干扰。

          回复

          1. 看来你已找到解决方案，但供他人参考：获取PR差异文件/补丁的最简方式就是在URL末尾添加.diff或.patch后缀。我一直这么操作！

            随机PR示例：https://github.com/microsoft/vscode/pull/280106 的差异文件位于 https://github.com/microsoft/vscode/pull/280106.diff

            另一点令人惊讶的是，GitHub的分叉项目实际上只是“魔法”分支。即分叉分支中的提交仍存在于原始仓库中：https://github.com/microsoft/vscode/commit/8fc3d909ad0f90561…

            回复

            1. 页面居然没有指向计划补丁的链接，这简直荒谬。虽然知道方法后添加后缀很简单，但很多人并不清楚——这个讨论串就是明证。

              用户体验中的可发现性似乎已彻底消失。

              回复

              1. > 页面居然没有指向计划补丁的链接，这简直荒谬至极。

                这不过是花园围墙上又添一块砖。眼下姑且保留，但还能维持多久？

                换言之，这是蓄意为之。更何况GitHub移植界面时，连删除项目、“添加评审”按钮这类基础功能都懒得添加。

                感觉他们已经不在乎了。

                回复

          2. 你可以设置一个驻留在云端的脚本(这样你就不必亲自操作)，通过webhook接收PR，获取关联的差异文件，并存储在S3中供你后续下载。

            或许还能写个脚本批量下载所有文件，并自动将每个差异应用到对应分支。

            Git及GitHub/GitLab等平台的操作几乎都能脚本化。只要愿意用传统管道传输文本，你完全不必在网站上动手操作。

            回复

            1. 既然简单邮件就能解决，何必让工作流变得复杂？

              > Git及GitHub/GitLab等平台的操作几乎都能通过脚本实现。

              此刻离开GitHub更多是理念层面的选择。当他们将Copilot投入生产环境那天，我也离开了这个平台。

              回复

    2. 我认为这是时间/生活管理问题：推送模式要求你立即行动。而拉取模式让我能在每周五下午查看业余项目的进展，投入几小时工作后便可收工，直到下周都保持不受干扰的状态。

      回复

  6. 我们正处于分散阶段：各类GitHub替代方案的公告源源不断涌现。我推测数月内，社群将最终聚焦于某一主导平台。值得玩味的是，它究竟会是现有平台之一，还是全新面孔？或许某知名企业或个人将推出新方案，凭借出色营销实现垄断。

    回复

    1. 这种现象已持续十年。初期是项目迁移至Gitlab，如今虽涌现大量替代方案，但GitHub仍是项目曝光率的唯一标杆。真正离开GitHub的项目仅占极小比例，现在断言GitHub末日来临为时尚早。

      回复

      1. 这就像每次非苹果厂商推出手机时，总有人高呼“iPhone杀手”。不过这种论调如今已基本消声匿迹。

        回复

      2. GitLab曾被寄予厚望。但它很快演变成比GitHub更庞大臃肿的单页应用(SPA)JavaScript程序。

        回复

      3. GitHub在项目发现方面表现尚可，但作为开发平台我认为它将走向衰落。公开问题/PR已沦为垃圾场且会愈演愈烈，而自动化工作流将促使企业倾向于隐藏开发流程。人们会逐渐转向替代方案，并在GitHub仍具相关性时同步镜像。

        回复

        1. 我始终选择GitHub只因它运行最顺畅。GitLab迟缓且卡顿，gitea及其分支功能匮乏令人倒退，Sourcehut的工作流则过于主观武断。至于GNU Savannah？别提了。

          自由软件/开源阵营中总有人哀叹GitHub的崛起，“因为显然你应该使用自由软件，这是你的道德义务！”但多数人(包括许多自由软件开发者)只是选择最有效的工具。虽然存在喧嚣的少数派(在HN这类圈子里尤甚)，但对大多数人而言，这充其量只是众多考量因素之一。

          GitHub能称霸的原因很简单：它就是最好用。这不代表它完美无缺(还记得代码示例中的行号功能花了多久才不再被复制粘贴吗？)，但其他替代方案更糟糕。

          有趣的是，他们现在正把平台搞得一团糟。你可能会以为，为一个相对简单的issue跟踪器重写基于React的前端应该不难，但事实并非如此。重写后的初期出现些bug很正常，但…都过去一年了？我至今在issue概览里仍经常看到已关闭的issue。返回按钮基本失效。这些不是什么晦涩的海森堡bug：使用五分钟就能发现的bug。整个使用体验简直糟糕透顶。

          我并不认为Github此刻正在衰亡。但我确信用户体验质量的退化是其终结的必要前提。如同许多事物，它的消亡将“在悄无声息中进行，然后突然间彻底终结”。Sourceforge曾看似无处不在，这种局面却在极短时间内逆转[1]。但谁又能预见五到十年后的局面呢？

          [1]：在此预先驳斥必然出现的“都是广告软件害的”论调——这完全是歪曲历史。广告软件出现时平台早已失去主导地位，不过是垂死挣扎的收入补救措施。

          回复

        2. 我猜主要收入来自非公开的企业账户。

          回复

    2. 不同开发者有不同的工作与协作偏好。我怀疑开源社区不会收敛于单一解决方案。当前正处于再去中心化阶段，开发者将根据个人/团队对控制权、托管管辖权、企业所有权与社区所有权、工作流程及运行时长的需求，将项目迁移至最契合的平台。

      这源于代码托管领域的竞争加剧。不同细分需求能获得对应解决方案是好事，即便对希望在冷门平台提交补丁的开发者而言会稍显不便。

      回复

    3. 更关键的问题在于：我们究竟需要一个主导性的替代方案，还是注定五年后重蹈覆辙？

      回复

    4. 我推测数月内社区将形成单一主导方案。

      路线图中的解决方案并非像GitHub那样中心化。当前存在推动联邦制的切实举措，使我们无需依赖单一实体。

      回复

      1. 我非常赞同这个观点，希望事情能朝着这个方向发展。或许可以换个角度思考：两年后，那些“Python入门教程”会引导用户走向何方？或许不会达成共识，但我的模式匹配大脑已经找到了答案！

        回复

    5. > 我推测数月内社群将形成单一主导平台。

      我真心希望不会如此。异构性在此领域极具价值，根本不存在“万能解决方案”。

      回复

    6. 我曾非常喜欢GitHub，甚至愿意为此多付费，但这似乎并非优先事项。在Safari浏览器上，PR审核功能因性能糟糕几乎无法使用，却未见任何可察觉的新特性。显然大量人力投入毁掉了这个产品，但我实在无法理解原因

      回复

      1. 不过好在他们内部应该也用Git，或许能找到可用的提交记录，直接撤销那些糟糕的改动。

        回复

    7. 这不就是GitLab吗？但大多数人还是更喜欢GitHub。

      回复

      1. GitLab对许多项目而言过于臃肿。它适合企业或GNOME这类大型组织，但管理起来又慢又麻烦。它在生态系统中占据重要地位，但我怀疑多数小型项目会选择它而非Codeberg这类更简单的替代方案。

        回复

      2. GitLab在各方面都逊于GitHub。

        至少GitHub会持续添加新功能。

        GitLab在明确表示不会这么做之后，仍不断移除功能以推销更昂贵的套餐。

        回复

        1. GitLab对我来说运行良好。工作上用了几年，最近把所有个人仓库都迁移过去

          回复

        2. > 至少GitHub会持续添加新功能。

          但反功能的推出速度更快，这是我的看法。

          回复

        3. 个人更倾向于 GitLab 的 CI/CD 配置而非 GitHub Actions。

          各有所长吧 ¯_(ツ)_/¯

          回复

      3. GitLab正是促使我产生这种想法的原因之一：作为GitHub知名且颇受欢迎的替代方案，它已存在多年。因此我本以为会看到“我们迁移到GitLab”的公告，实际却看到“我们迁移到CodeHouse”或“我们迁移到Source-Base”。而这里采用的自托管方案，还镜像到两个我并不熟悉的平台，更是另辟蹊径。

        回复

        1. 我认为人们对迁移到GitLab心存顾虑，因为它同样是个庞大的平台，大家不愿重蹈覆辙

          回复

    8. 他们似乎只顾抱怨前端和界面，却不愿承担版本控制之外的维护工作(即所有内置的Git功能)。

      你如何预测邮件系统的候选方案？

      回复

    9. 主导方案不会出现——自托管模式将更受欢迎。

      回复

    10. > 或许知名企业或个人会推出新方案；凭借出色营销实现垄断。

      哈，这正是我们Tangled的战略目标！近期将有重大公告。我们正定位为下一代社交协作平台——专注服务独立开发者与社区。

      回复

      1. 好奇问下，你用什么替代Git？为什么？ 🙂

        回复

        1. Darcs & Pijul——基于补丁理论的方案能消除整类合并冲突，使分布式协作更可行。这些分布式版本控制系统拥有更优(主观上更优)的基础架构，需要像代码仓库这样的工具支持——不像Git已有海量工具可选。

          回复

            1. 大多数版本控制系统都是如此。某天Linus说“让我展示正确做法”，于是诞生了Git，此后鲜有挑战者。

              回复

  8. > 在可用性方面，该平台随时间推移变得越来越慢

    这正是最关键的原因。

    回复

    1. 题外话，作为非母语者，我好奇“more and more slow”(越来越慢)是否比“slower and slower”更常见(或许是为了强调形容词？)

      回复

      1. 对我(母语使用者)而言，无论如何使用“more slow”都属于语法错误，尽管人们能理解其意。因此应使用“slower and slower”。

        回复

        1. 但作家可能出于风格考量使用这种结构。例：“比帝国更辽阔，却更迟缓。”

          我认为它本质上并非语法错误，只是因略显生硬而不常见。

          其可接受性在于：可刻意用于营造意象或引发思考——因为读者需要停顿解析。

          而使其“错误”的恰恰在于需要停顿解析。所谓“增加减少”实为语义模糊——减少本是可被增强的属性，故在语法上成立，但读者必须停顿揣摩才能理解，而非瞬间领会。

          回复

      2. “越来越慢”听起来更自然，“越来越慢”则显得怪异。

        回复

      3. 语言的衰败。他们先是剥夺了我们的副词，如今又开始攻击我们的比较级形容词。

        回复

    2. 说真的。这些年我总听人抱怨界面卡顿还得依赖JavaScript，但向来不以为意——反正对我管用。可最近页面加载速度简直慢得离谱。这问题恐怕不能全怪React，毕竟改用React时这些问题还没出现。

      现在我改用github.dev加载项目浏览仓库，这样只需付一次js税，看代码还算顺畅。但浏览PR和操作界面简直糟糕透顶。

      回复

  9. 我坦白承认自己对这个话题知之甚少，没什么建设性意见可提。关于此事我仅有四点补充：

    1. 哦！原来是“d.i.l.l.o.”！我误读成其他词了。

    2. 浏览本帖大量评论后，我不得不承认：仅是为项目搭建和维护版本控制系统所需投入的精力之巨，实在令人瞠目结舌。

    3. 原帖列举的所有问题，恰是我主张新项目改用自托管Fossil版本控制的依据。当你是小型组织里身兼软件工程师、系统管理员和二级以上技术支持时，这套系统对解决上述第2点尤为有效。它比Perforce更简洁，使用体验更接近Perforce。具体情况因人而异，但这类版本控制工具通常不会被列为简历技能项。

    4. GitHub部署密钥也令我困扰，因为无法为多个仓库使用同一密钥。我手头有三个独立应用，每个应用在集群中运行于四台机器上，这意味着我必须在GitHub和~/.ssh/config文件中配置12个独立部署密钥。

    回复

  10. 在我看来这是个不错的改进。顺便说一句，最近我发现自己使用dillo的频率越来越高了。

    由于微软的政策变动，我从GitHub转用了GitLab。目前我的需求很简单，GitLab似乎能满足。

    我还通过Gopher在sdf.org镜像了当前源代码。若GitLab出现问题，这里很可能成为我的主站点。

    回复

  11. > 为规避此问题，我开发了自有缺陷追踪工具buggy——这是个极简的C语言工具，能解析纯Markdown文件，并为每个缺陷生成独立HTML页面。

    我超爱这个方案。以前我一直是Linear的忠实用户(毕竟其他替代品都像狗屎)，但这也引发了一个问题：“为什么还要用独立且割裂的工具？”

    我个人项目大多有个TODO.md文件，里面列着待办事项。如果真需要前端界面管理bug，其实只需把那个Markdown文件渲染到网页上就够了。

    回复

    1. > 毕竟它只是纯文本

      若缺陷能仅用纯文本清晰描述，我当然支持这种方案。可惜大型软件项目中往往并非如此——我需要截图、上百兆的视频记录、跨问题关联等功能。我讨厌JIRA(当然)，但它确实做对了。

      回复

      2. 个人项目确实能凭记忆定位问题，甚至能指出具体代码片段。但团队协作时这种方式行不通

        回复

      3. 我们可以进入电子邮件地狱，直接将附件转换为base64字节流。

        回复

  13. 首要原因在于：

    > GitHub前端在禁用JavaScript时几乎无法正常工作，因此我们无法在Dillo浏览器内直接打开问题、拉取请求、源代码或CI日志——尽管这些内容基本都是纯HTML格式

    因为Dillo作为简化浏览器缺乏JS引擎。这完全是放弃GitHub的合理理由。

    回复

  14. > 尤其棘手的是，当活跃问题区充斥着从未参与项目却频频发表评论的用户时——这些评论往往弊大于利——最终导致开发者精疲力竭。

    这是GitHub的重大缺陷。我迫切希望打造这样的平台：问题可见性不受限制，但创建/修改权限严格限定于项目成员，非成员仅能通过讨论区反馈问题。我更倾向于基于“需求讨论”来亲自撰写问题报告。

    回复

  15. 我在本地运营数学兴趣小组，使用forgejo平台让孩子们提交LaTeX和Python解题方案。该平台运行流畅，且能轻松管理登录权限和密码重置。

    回复

  16. 非常棒。期待看到更多类似功能。

    GitHub的另一社会问题：在公开仓库使用“新手友好问题”标签时，必然会遭遇低质量的随意提交PR，或是机器人自动投递的AI垃圾代码。

    我认为集中化带来的问题仍被低估了。我认识的开发者似乎难以阅读非VS Code或GitHub页面呈现的代码。既然如此，何不干脆让所有人完全沉浸在GitHub Codespaces中开发？

    这正是善意人士所期待的：它解决了所有人的问题！开箱即用，无需额外配置！何必使用自己的设备或软件——那些无法定期向遥测地狱般的数据收集系统发送数据的工具？

    回复

  18. GitHub在存储Dillo项目所有仓库方面很有用，还能为我没有本地机器的平台(如Windows、Mac OS或某些BSD系统)运行CI工作流。

    帖子未提及CI的其他用途，他们是否在使用它？是保留在GitHub上还是打算移除？

    > 此外，该网页前端无需JS支持，因此可在Dillo浏览器中使用(我稍作修改使cgit CSS在Dillo上运行良好)。

    这种开发浏览器的方式似乎不太妥当，难道不该让Dillo正确兼容默认cgit CSS(无数项目都在使用)吗？

    回复

    1. 这固然是理想状态。但要支持cgit所需的所有CSS功能，其工作量很可能远超直接修改cgit的CSS。此举旨在避免“驴子剃毛”——即通过添加递归子项目，使项目工作范围远超原始计划的膨胀现象。

      Dillo项目正积极开发中，且“迁离GitHub”计划已完成，现在可以启动并完成其他工作(例如添加支持主线cgit所需的CSS功能)。

      回复

    2. > 帖子其他地方未提及CI，他们是否在使用它？保留在GitHub上？还是要移除？

      是的，我们拥有自主构建的CI服务，目前尚未对外开放。

      回复

    3. 这正是令我困惑之处。无论喜不喜欢，GitHub Actions是免费的。像Codeberg这样的替代方案对免费服务限制严苛得多，作者的解决方案似乎根本不包含CI功能。

      回复

  19. 是不是少了个’d’字母…

    关于GitLab与GitHub的对比：我理解GitLab功能更丰富，但实在无法忍受其默认界面。每次使用都比GitHub更令人烦躁。或许团队协作时GitLab更优，但从用户体验角度(主要指界面设计)，我认为GitLab不如GitHub。

    回复

  20. 之前没听说过forgejo，看起来挺不错的。

    回复

    1. Forgejo正是codeberg的运行平台，我认为这是替代github的绝佳选择

      回复

  21. > 它存在单点故障风险。我并非指GitHub存储在单台机器上，而是它由单一实体掌控，可单方面封禁我们的仓库或账户。

    除了微软臃肿软件的可用性问题外，这个战略要点在我看来被忽视得太多了。

    回复

  22. 看到项目转向自托管Git仓库而非反向发展总是令人欣慰。

    回复

  23. 虽然我不喜欢GitHub，但通过星标数量判断项目热度/价值确实有参考价值(当然这绝非完美指标)。星标数量低或分散在不同平台的项目，我基本不会尝试。

    回复

    1. Forgejo正在推进联邦化建设，期待未来能实现无需中心化服务商即可复制GitHub的项目发现能力。

      回复

    2. 天啊，可别让我们真要查看代码本身来判断项目优劣。

      回复

      1. GP明确声明他们用星标衡量仓库的人气而非代码质量。

        回复

  26. 不错！又找到能塞进Dillo的新地方了。

    回复

  27. 远离GitHub的充分理由在于它隶属微软(FAMAG；一家向特朗普献媚的公司)。

    Sourcehut托管于荷兰，Codeberg托管于德国。

    回复

    1. 理想状态是建立聚合平台：用户提交项目后，每个人都能通过自有网络连接托管，彻底摆脱对单一托管源的依赖。或许可以借鉴蓝天(bluesky)的AT协议模式，但应用于Git仓库。

      回复

        1. 实际上，它们似乎几乎完全符合我的设想。谢谢。

          回复

      2. 不妨看看[Fossil](https://fossil-scm.org/)，它非常容易部署，能提供代码仓库、缺陷追踪器、维基、论坛等功能。它虽非Git，但有桥接方案，甚至可将Fossil仓库镜像到Github。

        回复

      3. 纯文本需求可选Usenet、Freenet、Mastodon。不过这些平台功能远不止文本传输。

        我猜Tor网络上应该存在类似结合Git与源代码的解决方案。

        阿拉伯之春和香港抗议期间，当互联网被切断时，人们通过蓝牙传递信息。

        回复

  28. >最恼人的问题是前端在禁用JavaScript时几乎无法运行，

    他们不仅耗费数年将前端从Pjax重写为React(我猜是这样？)，还因此流失了客户。

    回复

    1. GitHub前端仍主要基于自研[1]Web Components库。他们用Turbo实现客户端自动刷新，仅在项目视图和重构的拉取请求审核等小范围内采用React视图。关键在于，即使禁用JavaScript，页面加载依然缓慢。亲测即可验证，前端代码似乎并非瓶颈所在。

      [1] https://github.blog/engineering/architecture-optimization/ho…

      回复

  29. 部分问题存在解决途径，例如使用GitHub API(我几乎完全依赖API)和/或用户脚本(详见下文)。此外，在GitHub及其他版本控制托管服务(如GitLab)中，可通过将URL中的“blob”替换为“raw”访问原始文件。但正如他们所说，代码可镜像至多个服务(包括自托管)，无论是否使用GitHub都值得采用此方案——若不喜欢GitHub，完全不必依赖它。

    需注意GitHub部分网页将数据以JSON格式嵌入HTML文件中，但该数据结构未公开且可能变更。用户脚本(可能因结构变更需持续维护)可实现无需服务器额外下载即可显示数据，且比GitHub专有脚本更简洁高效。

    使用GPG密钥对网页及发布版本进行签名颇有裨益(具体原因详见原文说明)，此外还有其他辅助措施(若阴谋论者未在多方面阻挠X.509证书的应用)。

    回复

  30. 在同一博文中，作者声称“不喜欢收到仓库活动通知，更倾向于’离线工作’并’仅在需要时检查’…”，同时详述了域名被广告垃圾网站收购者的经历。

    这难道不是剧本自带的桥段吗，伙计们？

    回复

    1. Dillo是我们中许多人熟知并使用的25年老项目。

      “冷门”是主观概念。它对你而言或许冷门，这无可厚非，但对许多人来说Dillo绝非冷门。

      回复

    2. Dillo非常酷，那篇博客远不止“我离开了Github”这么简单。

      内容相当有意思，推荐一读！

      回复

    3. 冷门？Dillo的存续时间比无数HN用户都长。

      回复

  33. 希望您能继续在GitHub维护镜像。当代码库文档匮乏时，deepwiki这类工具是绝佳的学习资源。但这些工具仅支持从GitHub拉取代码。

    回复

    1. 我的经历恰恰相反——我不得不屏蔽搜索结果中多个此类“绝佳资源”。

      回复

    2. 拉取操作为何依赖GitHub？

      Git拉取功能并非GitHub专属，它既支持HTTP也支持SSH协议？

      回复

      2. 问题核心不在于拉取操作本身，而在于DeepWiki这类工具默认其输入源位于GitHub，因此仓库URL被预设为GitHub格式而非任意位置的Git仓库地址。

        但这类工具设置此类限制的唯一动机，就是将用户导向其偏好的生态系统(即GitHub而非其他代码托管平台)。

        回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：