Do you have some GitHub architectural knowledge you’d like to share with us?
A push pushes commits and blobs and trees and tags. It’s an interesting metric to track, but the core unit of complexity (and expense) worth tracking on GitHub’s side is obviously the commit.
There’s a difference between pushing 1 commit and 100.
> There’s a difference between pushing 1 commit and 100.
There isn’t much. GitHub doesn’t run actions separately for each commit. It runs them on pushes. I’m trying to think of a thing that would happen for each commit in each push and coming up blank.
It does things like scan for references to issues to index, but it would just scan the log for a range.
I did disagree with GP though because there is no reason to assume that the ratio of commits to pushes has materially changed. So if that is the proxy they have always used for measuring growth, and they know it reliably does that then I think it’s a reasonable way to communicate this to this audience.
Sure, because pushes are how you update a reference. That’s really what triggers an action: a reference changing. And there could be a bunch of those in a push.
A commit costs storage, you’ve got secret scanning, it needs to be indexed in a way that can be referenced in commit messages and comments, a commit message itself can close issues or reference other PRs, stored and served individually and immediately via the web UI or git clients, etc etc.
None of the things you mention - indexing or secret scan would be done individually for each commit. As I already said, this would be a log of all commits in the range pushed - it would be scanned once for those things. There is no need for a loop running over a range of commits and processing each one.
There 100% is at least for things like secret scanning and message parsing.
Secret scanning needs to make sure my repo as a whole has no secrets. It’s not acceptable to have 1 commit introducing it and 1 removing it because the secret is still recoverable.
Every commit is also surely an entry in a database somewhere. I can navigate in GitHub directly to any individual commit so there is definitely some overhead of some type.
It's not necessary to perform secret scanning on a per-commit basis. The most efficient way is to just scan all blob objects being pushed; there is no reason to even be aware of an object's location (tree path or commit) except for diagnostic messages.
> I can navigate in GitHub directly to any individual commit
You can do the same with the git command line client. The overhead you claim is already in the git on-disk format. Github might very well duplicate this information in a database somewhere, but it doesn't follow from your observation.
You are right about secret scanning, but its worth noting that is only enabled by default on public repositories. It is an extra paid feature for organizations on a teams or enterprise subscription, and isn't available at all for individual owned repositories outside of an enterprise subscription.
And yes, I agree there is indexing of commits, but that is a batch insert from a log.
Sure but that’s how you beta test a runtime, by using it in a codebase you control. Claude is publicly released and used widely, that’s still only a single codebase
> I can definitely see someone being able to mount a good criminal defence case that they aren’t responsible for misrepresentations that an LLM agent makes on, for example, a loan application, if they sincerely intended to use the agent for non-fraudulent purposes. There won’t be intent, so they aren’t responsible outside of strict liability.
i mean, no? how would that be a good defence? "yes your honour, i lied on a loan application and committed fraud, but it was a mistake! i promise!" - that's... yeah. fine. it's not exactly unique.
regardless, it's _you_ making the loan application. not the agent. your failure to check it is on you.
you, the dog owner, would have a case against the trainer.
you, the person being bitten, would not give two craps about some story from the dog owner about how they hired a bad dog trainer who against their wishes secretly trained them to bite people.
you have been bitten. you have a case against the owner of the dog who bit you.
That was not my experience pre LLM's working with other software devs. I acknowledge that not everyone that writes software cares, but the majority of people I worked with pre-LLM did actually care that the software they wrote was bug free and well written before making a PR. With LLM's people seem to just get claude to vomit up whatever, give a quick review (if that) and press merge. Not sure if using LLM's made people care less, gave people an excuse to care less, or actually just don't care and were faking it before (or some combination of the above).
Relative poverty and enforcement: if a cop accepts a bribe they can lose their job. It’s not worth accepting £20 (or even £2000) bribe and forfeit larger future earnings.
So when bribes do happen it’s for much greater amounts (or nebulous, hard-to-trace things like favours), which rules out bribes for minor infractions.
> First of all tons of more outages than ever, remember that React useEffect fkup [0]? Complete insane that this would happen at an infra company that runs a third or so of the web.
Bugs happen all the time. They roughly increase with scale, not decrease. There’s an argument to be made about better testing, but this specific bug seems like a perfect one to slip through: multiple services, hard to spot at code review, involves JS/frontend, invisible at low traffic (test/UT envs).
So IMO it’s not completely insane. Is the implication that Cloudflare should have no bugs whatsoever?
If outages are increasing with scale you get 1 or maybe 2 free passes.
After that you either have in-ept Engineering or just in-ept leadership.
I used to be all in on CF a while ago, now I am moving off them almost entirely.
Same issue with GitHub, I can understand if you can't build for the scale when you couldn't predict it but if after over 12-18 months things don't seem to be improving what are you even doing?
I honestly think all of these companies are deluded if they think people will stick around with all these weekly outage events.
I have a homelab server I have had 2 outages in 1 year because my shitty ISP went down. Still at 99.9% uptime, I have done nothing special.
I now have backup internet as well.
Is it big? Nope but it doesn't need to be cf scale.
And scale is the reason to use these services why would I use cloudflare if a homelab would have been enough?
If they aren't designing and scaling their systems to handle this scale they might as well close shop, someone else might do it better.
As a infra/dev person who does his own thing on the side, I might be the most impacted by these outages, so I might be coming off as harsh. But they cost me both time/money and headache in extra development work.
Imagine prod deploys are down for 2 days why? Because GitHub actions keep failing...
Oh serving new OTA updates broke? Why? dig into the code.. go oncall with users instead of doing work, realize it's a CF outage and the writes failed.
(Feel the tears streaming down your face).
If I have to waste dev time, with AI and me together we could self host it with higher reliability with significantly cheaper costs at this point even at fairly decent scale.
I think any infra company that has more than 1 outage a year is already not worth investing in.
But more than 3 and you might be better off self hosting, even in this ram apocalypse.
If all people in SF are this unserious about reliability (which hasn't been my experience but HN seems especially open to break the prod if you have to)
Then well software companies really do deserve to be replaced by AI.
This might be rude but this is the reason we have shitty software everywhere. The "there can always be a bug, get over it mindset" is the reason software sucks, everything needs a dozen patches to even work and no one can have any peace in this business.
I honestly don't even want to debate this because I see no point, as honestly the side that would have said outages shouldn't happen is dead buried and out of a job at this point.
But,
> Saying “you’re not serious if you have more than 1 bug a year” is silly.
> Outages are just a specific kind of bug, often surfaced by the interactions of several discrete bugs.
Several bugs or 1 bug? you decide and tell me, when you have made up your mind.
Outages happen as a result of the system's design being shoddy in the first place, and an attitude where bugs shipped are acceptable because it's only a single component, rest of the system shouldn't fail.
It won't go down was the entire thing with microservices and "the cloud" I could link some blogs and brochures if you want me to.
I am honestly over the moon with these conversations on HN, really proves the point why AI is rightly replacing engineers in software, because there wasn't any engineering to begin with.
Imagine if a civil engineer said bridges fall it's fine for a few bridges to fall because bugs happen, and honestly bridge falling is just a kind of bug where several discrete bugs happened at once.
I am certain there is some room to argue about it, but what is clear is that if it was happening every single month you would have stopping using bridges unless absolutely necessary.
I am not sure if there is ever a reply for this honestly, I honestly don't even blame the people just the culture at this point. If that's what software is to some, "something that can fail at any time" and cloud's selling point is just fewer "switches to flip" I am sure I can't change that.
But I won't be deluded into thinking that software outages are just an everyday "bug" and it's fine to have several outages a year, it is the normal mode of operation in-fact no harm done.
> Outages happen as a result of the system's design being shoddy in the first place, and an attitude where bugs shipped are acceptable because it's only a single component, rest of the system shouldn't fail.
This is correct for some classes of failure but not others. If your authorization system goes down, should you just let any request pass? No.
You also need to fail correctly. If we extend the civil engineering analogy, then that would mean fail safely.
Two trains derailed in the UK last week. Should we all abandon trains? No? Why do plane crashes happen? That’s the most safety conscious area for software and hardware.
Because failures happen. Everyone expects them. Bridges don’t last forever, they know they will fail after a specific time frame and so they design around that. Planes have triplicate systems everywhere. And yet, despite all this, failures still happen.
And the fact they know that bridges have specific failure modes and lifespans is the result of a long, long history of bridges failing.
If trains were having fatal crashes every month I will and I think I speak for everyone of my friends in UK, they should stop using the train.
Same with airplane, but often thats the only solution if cloudflare is your only solution in your engineering problem I would much rather you re-review and reframe that problem.
No, not at all. Parquet is great for building static content incrementally, but it’s not great for this: the aim is durable writes (it’s a log system after all), but with parquet you need large row group batches. Worst case (low log volumes and a time-based flush) you’d end up with loads of tiny row groups.
You also need metadata in the file footer, so you can’t query it until the file is “done”. When is that?
It has to do that anyway?
reply