They are still high on their power trip. They say creators will have an “opportunity” because creators “think YT might have made a mistake”. What a huge ass announcement
Does anyone have performance issues with uuidv4? I worked with a db with 10s of billions of rows, no issues whatsoever. Would love to hear the mileage of fellow engineers
I've had issues in a database with billions of rows where the PKs were a UUID. Indices on PK, and also foreign keys from other tables pointing to that table were pretty big, so much so that the indices themselves didn't all fit in memory. Like we would have an index on customer_id, document_id, both UUIDv4. DB didn't have UUID support, so they were stored as strings, so just 1 billion rows took ~30 GiB memory for PK index, 60GiB for the composite indices etc. So eventually the indices would not fit in memory. If we had UUID support or stored as bytes it might have halved it, but eventually become too big.
If you needed to look up say the 100 most recent documents, that would require ~100+ disk seeks at random locations just to look up the index due to the random nature of UUIDv4. If they were sequential or even just semi-sequential that would reduce the number of lookups to just a few, and they would be more likely to be cached since most hits would be to more recent rows. Having it roughly ordered by time would also help with e.g. partitioning. With no partitioning, as the table grows, it'll still have to traverse the B-Tree that has lots of entries from 5 years ago. With partitioning by year or year-month it only has to look at a small subset of that, which could fit easily in memory.
What database were you using? For example with SQL server, by default it clusters data on disk by primary key. Random (non-sequential) PKs like uuidv4 require random cluster shuffling to insert a row “in the middle” of a cluster, increasing io load and causing performance issues.
Postgres on the other hand doesn’t do clustered indexing on the PK… if I recall correctly.
Postgres is not immune to uuid issues, just less sensitive, uuidv4 still does not play well with btree indexes, bloating them and impacting their performance.
Honestly not really. Yes random keys make inserts slower. But if inserts are only 1% of your database load, then yeah it's basically no issues whatsoever.
On the other hand, if you're basically logging to your database so inserts are like 99% of the load, then it's something to consider.
This isn't true according to this article: https://www.404media.co/how-ruby-went-off-the-rails/. Joel has a terrible habit of not citing his sources so I'm not sure if the post in question is the same but this seems to nullify that argument. TBF I do think there was pressure from Shopify to get compliance and security in order but saying "Shopify demanded that Ruby Central take full control of the RubyGems" is just plain not true.
The rubygems treasurer who is on the board said funding was conditional on doing this[0][1].
One interesting thing is that Ruby Central then said "Board decisions are independent and not contingent on funding."[2].
Doesn't inspire a lot of trust when there is a statement from a board member saying "we did this because of funding".
I'm more inclined to believe Joel's account.
[0] A deadline (which as far as I understand, we agreed to) loomed. Either Ruby Central puts controls in place to ensure the safety and stability of the infrastructure we are responsible for, or lose the funding that we use to keep those things online and going.
Ruby Central is making legal threats to its critics, so I hope you can see why people don’t feel safe to come forward on the record.
I can tell you that two people with direct knowledge of the situation told me that Shopify demanded that Ruby Central take full control of the RubyGems GitHub organisation and packages.
You can believe that I am lying if you want. But I can’t directly cite my sources in this case.
I never said you were lying. I said the quote that person pulled from your article isn't true. IIRC your article came out before the one I linked came out.
I believe the quote pulled from my article is true. Freedom’s original article lines up with what other people told me. I know he’s tried to retract it, but I don’t trust him to be truthful in this matter. He has lied about other things like the takeover being necessary for security.
Oh no, looks like you're one of today's (unlucky) 10000[0]. (For context I only heard about all this recently).
For the DHH thing he wrote a recent blog post where he said he wants fewer non-white people in London and praises an english far-right fascist figure (Tommy Robinson)[1].
Not really sure about the Shopify stuff. I've heard people aren't too fond of Tobi (the C.E.O. I think), and he's buddies with DHH, but it could just be general distrust of a big company trying to exert control of an open source project (through Ruby Central).
As an outsider to Ruby I kept hearing rumours and thinking it has to be exaggerated.
No, it turns out DHH really wrote a blog post complaining not enough people in London are white (even though they’re British) and praising a famous British fascist.
The rest is very much still confusing, some kind of opportunistic power plays and typical open source chaos.
