惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园_首页
Engineering at Meta
Engineering at Meta
量子位
A
About on SuperTechFans
阮一峰的网络日志
阮一峰的网络日志
Recent Announcements
Recent Announcements
博客园 - 司徒正美
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
腾讯CDC
Jina AI
Jina AI
C
Check Point Blog
H
Help Net Security
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
爱范儿
爱范儿
I
InfoQ

Hacker News

GitHub - SeanFDZ/macmind: Single-layer transformer in HyperTalk for the classic Macintosh Show HN: Agent-cache – Multi-tier LLM/tool/session caching for Valkey and Redis Bonsai 1-bit WebGPU - a Hugging Face Space by webml-community Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus GitHub - Nightmare-Eclipse/RedSun: The Red Sun vulnerability repository GitHub - SethPyle376/hiraeth: Local AWS emulator focused on fast integration testing, with SQS support, SQLite-backed state, and a debug-friendly web UI. GitHub - macOS26/Agent: Any AI, replaces Claude Code, Cursor, OpenClaw. Over 18 LLM providers (Claude, OpenAI, Gemini, Ollama, Zai, HF, Qwen) wired into a native Mac app that writes code, builds Xcode projects, bumps versions, manages git, automates Safari, use AppleScript, JS or Accessibility, extend Agent! w/ MCP Servers, run tasks from your iPhone via Messages. YouTube now lets you turn off Shorts I Made a Terminal Pager Burgers | マクドナルド公式 Commands — HackerNews CLI documentation ChatGPT for Excel PiCore - Raspberry Pi Port of Tiny Core Linux Live Nation illegally monopolized ticketing market, jury finds Google Broke Its Promise to Me. Now ICE Has My Data. Founding Engineer at Adaptional | Y Combinator CRISPR takes important step toward silencing Down syndrome’s extra chromosome GitHub - saffron-health/libretto: The AI toolkit for building reliable browser automations US v. Heppner (S.D.N.Y. 2026) no attorney-client privilege for AI chats [pdf] Retrofitting JIT Compilers into C Interpreters IPv6 – Google The Accursèd Alphabetical Clock Cybersecurity Looks Like Proof of Work Now Fragments: April 14 Cal.com Goes Closed Source: Why AI Security Is Forcing Our Decision | Cal.com - Scheduling Software for Online Bookings Laravel raised money and now injects ads directly into your agent When moving fast, talking is the first thing to break Too much Discussion of the XOR swap trick – Heather Cafe Introduction to Spherical Harmonics for Graphics Programmers The Grand Line
Handling the great code forge fragmentation
2026-05-17 · via Hacker News
Picture of shower tiles that look like 10x developer git history

The kind of developer I hope to be someday

It seems like there are a lot of people either leaving or talking about leaving Github, a very prominent one being Mitchell Hashimoto. Fragmentation seems inevitable, as people/companies start to distribute among the various options (Codeberg, self-host Forgejo, Gitlab, etc…). I think the decision Hashimoto makes with ghostty will potentially set the tone for how the death of Github will happen. I have some scattered thoughts about the situation:

Tracking activity across providers

I hope to someday be a 10x bathroom tile developer with a git contribution heatmap being a solid color. I have already had an issue with tracking my progress working on repositories split between my self-hosted Forgejo instance and Github. I’m a simple man that wants to see my contributions measured on a public heatmap for both satisfaction and motivation. So I solved this problem for myself with a go script and hugo module that you can use to create a git heatmap combining data from multiple hosting platforms. Just takes one go command to generate the activity file, some hugo config changes, and a simple shortcode embedded in your hugo markdown.

[Github repo available here]

This is my unified git heatmap from my Forgejo and Github

I also have some random thoughts I wanted to write out about the whole situation.

Some kind of trust system is needed to stop AI slop

I think the years of allowing contributions from anyone with an account is over for open source. Maintainers are drowning in AI generated PRs/issues from unvetted sources. Even though AI contribution quality is reported to be improving1, the core volume issue isn’t. The current system is requiring maintainers to wade through PRs/issues that potentially took 0 human effort/time to produce. Even if some of them are useful/correct, the sheer volume makes the entire system intractable. You guys already probably know this.

Hashimoto has a solution to this called vouch that is currently being developed. It tracks approved/blocked contributors on a repo basis using a Github actions workflow by appending usernames to a VOUCHED.td file. The syntax of the file is:

# Vouched contributors for this project.
#
# See https://github.com/mitchellh/vouch for details.
#
# Syntax:
#   - One handle per line (without @), sorted alphabetically.
#   - Optional platform prefix: platform:username (e.g., github:user).
#   - Denounce with minus prefix: -username or -platform:username.
#   - Optional details after a space following the handle.
aselimov
github:aselimov

This is a step in the right direction, but I still think a trust system needs to be built into the forge platform. Ideally you would also be able enable vouch chaining somehow. Effectively

aselimov VOUCHED by user1 on repo1
user1 VOUCHED by user2 on repo2
aselimov indirectly VOUCHED for repo2

I think we need a web with some barrier of entry to ensure contributors are high quality and motivated instead of bots that will write hit pieces2.

Get your username locked in NOW

If we are transitioning to a vouching based trust model you are going to want to lock in a consistent username across the main platforms. That way, if a cross-platform trust chain is established, you will have fewer issues from username squatters impersonating you. Seems like the main Github alternatives are:

  • Codeberg
  • Gitlab
  • Bitbucket

Personally I think Codeberg/self-hosted Forgejo is the best option, but you probably should make an account on each just in-case.

Is self-hosting the right tool to stop AI slop?

Self-hosting Forgejo is the maximally guarded vouching system. In most cases3, the host disables account creation to not get inundated with spam/malware. To get account access, you have to reach out to either the host or a known admin to get registered. Probably this means sending an email, LinkedIn message, DM on x, etc… I’m not completely opposed to this concept if I ever spin up a project successful enough to be targeted by the slopocalypse.

Mirroring self-hosted repos to Github for engagement

My current workflow does involve mirroring all of my repos to Github to enable some level of community engagement. The main motivating factor is to enable some sort of issues tracker, but receiving PRs is a nice bonus. Migrating the PR from Github to Forge requires manual effort on my part which acts as a hardening step. It ensures that I need to approve the PR before it gets anywhere close to my CI. This could be a layer of protection if my brain stops working, and I start introducing vulnerable actions4 by mistake.

Conclusion

  • Add a unified git activity map to your hugo site!
  • Establish your username/identity on all of the major forges.
  • I have no idea where things are going from here or if Github can recover.

  1. Curl maintainer talking about how the AI slop storm has actually turned high quality https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/↩︎

  2. A maintainer of matplotlib closed a PR because it was a good first issue for a human and the PR was opened by an openclaw bot. The bot then wrote a blog post naming the maintainer as an anti-ai gatekeeper https://crabby-rathbun.github.io/mjrathbun-website/blog/posts/2026-02-11-gatekeeping-in-open-source-the-scott-shambaugh-story.html ↩︎

  3. I’ve done this on my instance and I think it’s the Forgejo default setting. ↩︎

  4. Using pull_request_target can allow someone opening a PR to execute code in the runner context. ↩︎