2·
2 days agoAre you sure about that?
Github’s “highscore” for consecutive days without incidents this year is 6.
- 0 Posts
- 3 Comments
Joined 3 years ago
Cake day: June 19th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
I’m perfectly happy with this.
Why?
Because at the end of the day, the users of the code forge can be broken up into three categories:
- Traditional coders with human made projects
- Vibe-coders who slop out 100 throw away projects, each of which is a dead project as soon as that user moves onto the next project
- Vibe-coders who focus work on only a single project.
Category 1:
- Code forges were already valuable before LLMs, so we already have a proof of value/utility/whatever for hosting projects from users in category 1.
Category 2:
- Projects from the users in category 2 have a half life of a couple of weeks.
- They’re so quickly made that most of their contents is going to be rehashes of previous existing content, so there’s a reduced value holding on to them as reference when the original sources exist.
- Since they were generated so quickly, a more up-to-date version can be generated in the future if they’re ever needed again.
- Since the projects aren’t going to be used by others, they don’t actually use the features of a code forge, so it’s not a great idea to allocate so many resources that aren’t going to be utilised to host them on a community code forge. A better place for them would be cloud storage (dropbox, google drive, etc…). Most cloud storage services have a free tier. Anyone with a crazy amount of projects and assets that would exceed free tiers and who just wants to hold onto the projects for the future can use something like S3’s glacial deep archive which is about $1.20USD a year to hold onto 100GB of zipped up projects.
Category 3:
- These projects may actually get used by people
- Since they’re developed with LLMs, there’s so much churn that there’s no actual point of reading the code since it’s quickly out of date. That means there’s no use for using the code forge’s source file features
- Issues that reference code will go out of date as soon as the code goes out of date which is far more likely than with category 1 users.
- These projects tend to have so much code churn that their builds are more inefficient than hand coded projects. This means that they’ll tend to want more powerful hardware to run their CI/CD pipelines than a community code forge can provide. So from their perspective, they’re better off running their own code forge anyway.
Keeping category 1 users on community code forges, saving the code forge’s resources from being used by community 2 users, and letting community 3 users tailor their own code forges for their own needs seems like a win for everyone actually using the community code forge, and not those treating it as a file dump.
Yes. Remember there are two different main types of github users.
Users in the first group won’t notice anything going wrong until only the services they use are affected.
Users in the second group experience full blown “intelligence brownouts” when any service goes down because they’re coupled so strongly together. That’s why that metric is useful (and also because it shows the true “number of nines” used in SLAs).
And, github is doing every insidious trick they know to push group 1 users into becoming group 2 users.
If github weren’t trying to force users into the second group, then I think we could give them some more leeway here. But they’re not, so yes github is much much worse.
If you want something a bit more granular, then you can check: https://mrshu.github.io/github-statuses/