Yeah the cheapest time to buy old tech is always just when the new stuff has come out. That's when suppliers are trying to shift old stock at cheaper margins.
You can take a look at the 5800X3D and how it was at its cheapest about 2 years ago when AMD was winding down production and Zen 4 had been launched.
To further your point, a used 5800X3D still goes for ~$300 when you can get a brand new 7800X3D for the same if not slightly cheaper (was on sale at MC for $280). I assume the high cost of DDR5 is pushing more people to not upgrade to AM5 and stay on AM4 for as long as possible. And most people are avoiding Intel chips out of principle after the chip degradation debacle - you can see that based on how much lower Intel motherboards are even though they have considerably better feature sets than the AMD equivalents.
Main reason for Intel boards being cheap is because they're practically one and done because of Intel's insistence on changing sockets every other generation.
The main issue there is you need someway to pay the engineers in that transitional period the moment Mozilla collapses. Otherwise they leave, find new jobs, and you lose all the expertise and knowledge of the codebase.
That assumes you can add compute in a vacuum. If your altcoin receives 10x compute then it becomes 10x more expensive to mine.
That only scales if the coin goes up in value due to the extra "interest". Which isn't impossible but there's a limit, and it's more often to happen to smaller coins.
The one thing to be careful with Zen 2 onwards is that if your server is going to be idling most of the time then the majority of your power usage comes from the IO die. Quite a few times you'd be better off with the "less efficient" Intel chips because they save 10-20 Watts when doing nothing.
UUIDv7s are much worse for creation time though imo. For sequential IDs an attacker needs to be have a lot of data to narrow the creation time. That raises the barrier of entry considerably to the point that only a committed attacker could infer the time.
With UUIDv7 the creation time is always leaked without any sampling. A casual attacker could quite easily lookup the time and become motivated in probing and linking the account further
> For sequential IDs an attacker needs to be have a lot of data to narrow the creation time.
When sequential integer ID's are externalized, an attacker does not need creation times to perform predictive attacks. All they need to do is apply deltas to known identifiers.
Then that's just worse and more complicated than storing a 64 bit bigint + 128 UUIDv4. Your salt (AES block) is larger than a bigint. Unless you're talking about a fixed value for the AES (is that a thing) but then that's peppering which is security through obfuscation.
Uhh... What? You just use AES with a fixed key and IV in block mode.
You put in 128 bits, you get out 128 bits. The encryption is strong, so the clients won't be able to infer anything from it, and your backend can still get all the advantages of sequential IDs.
You also can future-proof yourself by reserving a few bits from the UUID for the version number (using cycle-walking).
With PostgreSQL my biggest concern is what happens when we no longer have Tom Lane, Petere, etc. Rather than the project dying I see the opposite happening; it gets feature crept by contributors adding in their own custom behaviour and it becoming too complex.
There's always a large overhead of adding something new and it's always the experienced devs on the project that know where the right balance is.
No project or development style is perfect and they all come with their own set of upsides and downsides. PostgreSQL is no exception. Maybe the PostgreSQL 20 years from now will be a different type of project with different types of trade-offs. That doesn't mean it will be worse. I'm not so worried about this.
There's been community forks of it since then that I switched to and will continue to use instead. Grouping tabs at the top is much worse UX than an entire page you can drag and drop around, and blatantly copying Chrome.
What percent of their users even have telemetry enabled? Mozilla always pulls this crap, using these biased telemetry numbers as a fig leaf to drop genuinely useful features. Luckily they still allow for community modification.
Sadly, this seems to be the general purpose of telemetry. If the gathered statistics can be contorted to justify doing something you wanted to do anyway, then telemetry will be used for just that. If it says something else, just ignore it and say you don't have enough resources or something.
Proponents suggest it is necessary to improve software. Microsoft has extensively used telemetry for at least 10 years in Windows, does that feel improved to anyone during that time? I'm of the opinion they largely used it to identify what existing features users were still being productive with so they could be enshitified next.
It's doubly bad with postgres because the statistics get wiped after running pg_upgrade. They do tell you to run ANALYZE afterwards but that's yet more downtime.
That's not great, do the bucket counts change or something between versions? It seems like statistics would be a thing that ... should not change while you are not looking!
You can take a look at the 5800X3D and how it was at its cheapest about 2 years ago when AMD was winding down production and Zen 4 had been launched.
reply