
Days since last Github service disruption: 0
I found out when Actions started failing again for the Nth time this month.
The internal conversation about moving away from Actions or possibly GitHub has been triggered. I didn't like Zig's post about leaving GitHub because it felt immature, but they weren't wrong. It's decaying.
If you consider that an American maintainer was cheesed off enough to move an entire project off GitHub two days before Thanksgiving then the tone of the original post was completely in line with the energy involved.
Anger is a communication tool. It should absolutely be used when boundaries are being violated. Otherwise you’ll get walked all over.
I mostly agree, but a generalized attack at the remaining GitHub workers by calling them "losers" and then "rookies" is unwarranted and leaves a bad taste IMO.
See the edit history here: https://news.ycombinator.com/item?id=46133179
Edit: 1. just to be clear, it's very good that they have accepted the feedback and removed that part, but there's no apology (as far as I know) and it still makes you wonder about the culture. On the other side, people make mistakes under stress. 2. /s/not warranted/unwarranted/
A structural engineer will not sign off on bad designs no matter how much pressure the company applies to them. They will resign and/or report the incident to their local regulator as a safety issue.
We don't have that for developers. Maybe shame/offense is our next best bet. You are free to work for a terrible company accepting and/or encouraging terrible design decisions, but you need to take into account the potential of being laughed at for said decisions.
Idk, if being bad is the reason for leaving Github Actions, I think people would have left it ages ago. It stuck not because it is better than competitors but because it is included in the Github plans. It's decaying implies that it has somehow became worse, in fact it was one of the worst implementation to start with.
The Zig post has since been updated and the objectionable parts have been removed. I think we can put that part to rest.
I have no problem with their opinions but I don’t think it should have been said in a Foundation post.
It may have been updated, but nobody is reading the update.
Combined with security concerns, this made us reconsider even our self-hosted GH Actions last month.
GH Packages is something we're extricating ourselves from after today too. One more outage in the next year and maybe we get the ammunition to move away from GH entirely.
It's still hard to believe that they couldn't even keep the lights on on this thing.
GitHub has seem to come under the same management as VSCode, everything has to be made AI and that is the only priority. It's like the Google+ of old but stupider.
Hopefully with that much AI they can finally make the Explore page more useful than "most stars" and "most recent updated". There seems to be no way to discover stuff on GitHub except knowing where it is (hence not discovering but knowing).
[dead]
This is why I keep encouraging folks to a) have a mirror & b) make sure their tools automatically pick up the mirrors.
I recently got mirror support upstreamed into Nixpkgs for fetchdarcs & fetchpijul which actually work on my just-alpha-released pinning tool, Nixtamal <https://darcs.toastal.in.th/nixtamal/trunk/README.rst>, for just this sort of thing.
I envy you. Most of us struggle to get the resources to make our actual customer facing applications resilient, let alone our build pipeline.
Building your software usually involves getting dependencies, & those dependencies are, hopefully, in more than one location—which includes a cronjob to a bare repo, or Alice’s fork on another repo that at least has the latest tags. It should be trivial to point to these as mirrors for the cases where any forge/repository, even the ones held by megacorporations, inevitably go down. Even Nixpkgs itself, while not maintaining their own official mirrors, are mirrored by TUNA. Backups are an important strategy, & the source code should also be a part of that.
That's great for the repository, but what about if you're using ghcr, actions, issues, or copilot?
These are different concerns. There are a lot of use cases, where folks are just getting dependencies & not interacting with bug tracker or continuous integration use which are less critical & can be accessed later or ran locally.
I've been getting some weird cryptocurrency spam notifications on GitHub and they can't be cleared for some reason. Blue dot is gonna be there forever apparently. Some users made an issue out of it but nobody cared to fix it.
This should have been fixed here: https://github.blog/changelog/2025-12-04-notifications-trigg...
Are you still seeing it, would you mind checking? Our team will get on it if so.
I had the same. The dot is cleared on the mobile site. It is present on the desktop site.
Somewhat similar situation here. Cleared cache and logged back in on mobile, dot was fixed. Haven't tested on my laptop yet.
Thank you all, sharing internally now to get that fixed! Super appreciate the feedback.
Thanks for fixing it!
Had the same issue that the blue dot won’t disappear. I was able to clear the dot with:
gh api notifications -X PUT -F last_read_at=2025-10-06T00:00:00Z
Just change the date to today. I also got that line from a gh issue somewhere - maybe it was the same issue that you’re referring to.
Same happened to me. You can clear it via the CLI, hilariously.
```
gh api notifications\?all=true | jq -r 'map(select(.unread) | .id)[]' | xargs -L1 sh -c 'gh api -X PATCH notifications/threads/$0'
```
HN doesn't support markdown, but you can "code" format it with 2+ spaces.
Here’s how you can clear it:
https://github.com/orgs/community/discussions/174310#discuss...
I had the same issue too, and this was the only thing that fixed it for me.