Readit News logoReadit News
luhn commented on Self-hosting your own media considered harmful according to YouTube   jeffgeerling.com/blog/202... · Posted by u/DavideNL
somenameforme · 3 months ago
I think their real edge is a practically free and practically infinite bandwidth/capacity global CDN setup. There's no real technical reason for this still to be the case, but bandwidth costs are significant for people relying on other services to provide such. Or they're cheap and slow/capped.

This is the main reason I think alternative sites have a hard time competing. Play anything on YouTube from anywhere and if it's buffering/slow then it's probably your internet connection that's the problem. By contrast do the same on competing streaming sites and it's, more or less, expected especially if you aren't in certain geographic areas.

Monetization on YouTube is mostly just a carrot on a stick. The overwhelming majority of content creators will never make anything more than pocket change off of it. That carrot might still work as an incentivization system, but I don't think it's necessarily the driving force.

luhn · 3 months ago
Yeah, anybody can make a half-baked CDN, but Google has PoPs inside ISPs across the world [1] and competing with that is essentially impossible.

[1] https://support.google.com/interconnect/answer/9058809?hl=en

luhn commented on The key to a successful egg drop experiment? Drop it on its side   arstechnica.com/science/2... · Posted by u/samizdis
plasma_beam · 3 months ago
In high school physics I procrastinated until the night before our egg drop competition to finally address what I was going to do. I got a medium/large size plastic tupperware container (rigid plastic body with a rigid lid). I took a bag of cotton balls, stuffed them in there as tight as I could, put an empty cardboard toilet paper roll vertically in the center, with more cotton balls designed to go in said cardboard below and above the egg. Taped the lid shut. People laughed at my concoction, especially those that went to great efforts to design theirs. I even tossed mine in the air beforehand to test it, which gave me extreme confidence going into the 30 ft drop that I'd be fine. I was. I do not recall what side it landed on but obviously it bounced several hard times after hitting the ground.
luhn · 3 months ago
Yeah, tight packing is simple and very effective. I had a successful drop with nothing but corn starch packing peanuts shoved into a cardboard box.
luhn commented on Migrating to Postgres   engineering.usemotion.com... · Posted by u/shenli3514
nasretdinov · 3 months ago
Does adding a default value into a column finally work without locking up an entire table now at least?
luhn · 3 months ago
Like most ALTER TABLE subcommands, you need an exclusive lock on the table while the catalog is updated. But no table scan or rewrite is required, so that lock is sub-second and can usually be done without disrupting a live application.
luhn commented on Migrating to Postgres   engineering.usemotion.com... · Posted by u/shenli3514
icedchai · 3 months ago
You don't even need to be that "modern." Back in 2010 I was working on a MySQL 5.x system with about 300 million rows on a dual Xeon box with 16 gigs RAM and a few hundred gigs of RAID 10. This was before SSDs were common.

The largest table was over 100 million rows. Some migrations were painful, however. At that time, some of them would lock the whole table and we'd need to run them overnight. Fortunately, this was for an internal app so we could do that.

luhn · 3 months ago
The improvements to migrations have been the biggest boon for running even modestly-sized Postgres DBs. It wasn't that long ago that you couldn't add a column with a default value without rewriting the whole table, or adding NOT NULL without an exclusive lock while the whole table was scanned. That becomes unfeasible pretty quickly.
luhn commented on Migrating to Postgres   engineering.usemotion.com... · Posted by u/shenli3514
casper14 · 3 months ago
Nice! What optimizations have you put in llace yo support 150 mil? Just some indexing or other fancy stuff?
luhn · 3 months ago
You don't need to optimize anything beyond appropriate indices, Postgres can handle tables of that size out of the box without breaking a sweat.
luhn commented on Migrating to Postgres   engineering.usemotion.com... · Posted by u/shenli3514
luhn · 3 months ago
> By Jan 2024, our largest table had roughly 100 million rows.

I did a double take at this. At the onset of the article, the fact they're using a distributed database and the mention of a "mid 6 figure" DB bill made me assume they have some obscenely large database that's far beyond what a single node could do. They don't detail the Postgres setup that replaced it, so I assume it's a pretty standard single primary and a 100 million row table is well within the abilities of that—I have a 150 million row table happily plugging along on a 2vCPU+16GB instance. Apples and oranges, perhaps, but people shouldn't underestimate what a single modern server can do.

luhn commented on Jepsen: Amazon RDS for PostgreSQL 17.4   jepsen.io/analyses/amazon... · Posted by u/aphyr
ashu1461 · 4 months ago
Have one question

So if snapshot violation is happening inside Multi-AZ instances, it can happen with a single region - multiple read replica kind of setup as well ? But it might be easily observable in Multi-AZ setups because the lag is high ?

luhn · 4 months ago
A synchronous replica via WAL shipping is a well-worn feature of Postgres. I’d expect RDS to be using that feature behind the scenes and would be extremely surprised if that has consistency bugs.

Two replicas in a “semi synchronous” configuration, as AWS calls it, is to my knowledge not available in base Postgres. AWS must be using some bespoke replication strategy, which would have different bugs than synchronous replication and is less battle-tested.

But as nobody except AWS knows the implementation details of RDS, this is all idle speculation that doesn’t mean much.

luhn commented on Jepsen: Amazon RDS for PostgreSQL 17.4   jepsen.io/analyses/amazon... · Posted by u/aphyr
luhn · 4 months ago
It's not mentioned in the headline and not made super clear in the article: This is specific to multi-AZ clusters, which is a relatively new feature of RDS, and differ from multi-AZ instance that most will be familiar with. (Clear as mud.)

Multi-AZ instances is a long-standing feature of RDS where the primary DB is synchronously replicated to a secondary DB in another AZ. On failure of the primary, RDS fails over to the secondary.

Multi-AZ clusters has two secondaries, and transactions are synchronously replicated to at least one of them. This is more robust than multi-AZ instances if a secondary fails or is degraded. It also allows read-only access to the secondaries.

Multi-AZ clusters no doubt have more "magic" under the hood, as its not a vanilla Postgres feature as far as I'm aware. I imagine this is why it's failing the Jepsen test.

luhn commented on Who killed the rave?   ft.com/content/2138e940-0... · Posted by u/this_weekend
janalsncm · 8 months ago
> enough homes to house its population twice over

This is because a ton of them are in the Chinese equivalent of like Boise, Idaho where demand is fairly low. People want to live where the high paying jobs are.

luhn · 8 months ago
I get your point, but that's a terrible example because Boise is one of the fastest growing metro areas in the country.
luhn commented on Mouseless – fast mouse control with the keyboard   mouseless.click/... · Posted by u/lvturner
luhn · 9 months ago
Years ago my Mac got confused and seemed to think my keyboard was a mouse. Pressing any key would move the cursor up a few points.

Ahead of its time, I guess.

u/luhn

KarmaCake day3512September 18, 2015
About
[ my public key: https://keybase.io/luhn; my proof: https://keybase.io/luhn/sigs/axzqWHr-c1jSTvNkMykCX2WQJPqHAetp_3ouwg3p950 ]
View Original