[flagged]
It's a new repo. What do you expect? I expect a new repo to be empty or nearly empty.
Congratulations on creating the one billionth repository on GitHub
101–110 of 146 posts
Re: Congratulations on creating the one billionth repository on GitHub
#102Earlier quoted context omitted.
>following new repos and scanning them for leaked credentials could be a negative People do this. GitHub started doing it too so now you get a nice email from them first instead of another kind of surprise.
Email, bleh, I'm sure I'm not the only one who basically /dev/null's emails from github about pearl-clutching "security" but I wanted to point out that for quite a few providers they actually have an integration to revoke them if found in a public repo, which I think is way more handy https://docs.github.com/en/code-security/secret-scanning/sec... and the list is way bigger than I recalled: https://docs.github.com/en…
You can turn those GitHub security warnings off if you don't want them.
>quite a few providers they actually have an integration to revoke them if found in a public repo, which I think is way more handy
Yes I've also gotten an email from Amazon saying they revoked a key someone inadvertently leaked (but so long ago I only remember that it happened). I read my AWS emails at least.
Re: Congratulations on creating the one billionth repository on GitHub
#103[flagged]
Well 90% of everything is shit [1], so it's a fair representation. [1] https://en.wikipedia.org/wiki/Sturgeon%27s_law
Your comment is funny but also not a joke. I think it's true. Some people seem to think this was a staged prank. I think the reality is that a lot of repos are just kids (or adults!) learning git with a friend and typing silly things in to keep things fun.
Re: Congratulations on creating the one billionth repository on GitHub
#104Probably created via a script that just repeatedly checked https://api.github.com/repositories/999999999 until it showed up, and then created a new repository. Since repositories can be modified, could have even given it some buffer and created a bunch of repos, just delete the ones that don't get the right number. [append] Looking at the author's other repo created yesterday, I'm betting "yep" was supposed to be the…
Or...not. Why are you assuming this guy purposely grabbed the repo?
Mostly just to share an approach to solving the "problem" of getting memorable numbers from a pool of sequential IDs.
But given that this user doesn't have activity very often, and created two repositories as the number was getting close, it feels likely that it was deliberate. I could be wrong!
Re: Congratulations on creating the one billionth repository on GitHub
#105Earlier quoted context omitted.
I bet you haven't seen indeces on decimals though! Fun times :)
Just curious as someone with limited experience on this. Whats wrong with it? decimal is consistent & predictable (compared than float), so it shouldn't be that big of a deal right? CMIIW
Yeah, not a big deal but completely useless nonetheless as you would never really query your table for just the one decimal column (eg the price) but a couple more (eg the category and the price) so you'd have a multi-column index on those columns. The index on just the price column never gets used.
Re: Congratulations on creating the one billionth repository on GitHub
#106Earlier quoted context omitted.
What are the challenges of such projects? How many people are usually involved? Does it incur downtimes or significant technical challenges for either the infrastructure or the codebase?
If you've written your services in JavaScript, going from i32 to i64 means your driver is probably going return it as a string (or a BigInt or some custom Decimal type), rather than the IEEE754 number you were getting before. This means you now need change your interfaces (both internal and public-facing) to a string or some other safely serializable representation. And if you are going to go through all that trouble…
Maybe you are better off moving to UUIDs then? It seems that there's packages to make handling them easier, but you'll still need a tiny hack to map old i32 Ids to some UUID.
Re: Congratulations on creating the one billionth repository on GitHub
#107Awesome! Only a little over a billion more to go before GitHub’s very own OpenAPI Spec can start overflowing int32 on repositories too, just like it already does for workflows run IDs! https://github.com/github/rest-api-description/issues/4511
The company where I did my stint as CTO I turned up, noticed they were using 32-bit integers as primary keys on one of their key tables that already had 1.3 billion rows and, at the rate they were adding them, would overflow on primary key values within months… so we ran a fairly urgent project to upgrade the IDs to 64-bit to avoid the total meltdown that would have ensued otherwise.
The same story happened inside Amazon.
Re: Congratulations on creating the one billionth repository on GitHub
#108Earlier quoted context omitted.
The company where I did my stint as CTO I turned up, noticed they were using 32-bit integers as primary keys on one of their key tables that already had 1.3 billion rows and, at the rate they were adding them, would overflow on primary key values within months… so we ran a fairly urgent project to upgrade the IDs to 64-bit to avoid the total meltdown that would have ensued otherwise.
What are the challenges of such projects? How many people are usually involved? Does it incur downtimes or significant technical challenges for either the infrastructure or the codebase?
I remember such a project, and due to our large and aging TypeScript frontend projects it would have added a couple of weeks to adjust all the types affected. All IDs in many places deep in code caused thousands of errors from the mismatch which was a nightmare. I can't remember exactly why it was so tough to go through them all, but we were under intense time pressure.
To speed things up we decided to correct the ID types for the server response, which was key since they were generated from protobuf. But we kept everything using number type IDs everywhere else, even though they would actually be strings, which would not cause many issues because there ain't much reason to be doing numeric operations on an ID, except the odd sort function.
I remember the smirk on my face when I suggested it to my colleague and at the time we knew it was what made sense. It must have been one of the dumbest solutions I've ever thought of, but it allowed us to switch the type eventually to string as we changed code, instead of converting the entire repos at once. Such a Javascript memory that one :)
Re: Congratulations on creating the one billionth repository on GitHub
#109The repo seems to have gotten renamed and now redirects to https://github.com/AasishPokhrel/repository/
Lame. :-(
Re: Congratulations on creating the one billionth repository on GitHub
#110On a serious note, I'm a bit surprised that GitHub makes it trivial to compute the rate at which new repositories are created. Isn't that kind of information usually a corporate secret?
You can see the rate of creation of new users too.
Which is arguably even more interesting…