blackenedgem

See also, every new iPhone/Pixel being the best they've ever release. You'd hope so!

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.

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

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.

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.

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.

>One known issue is that vacuum will become an issue if the load is persistent for longer periods leading to bloat.

Generally what you need to do there is have some column that can be sorted on that you can use as a high watermark. This is often an id (PK) that you either track in a central service or periodically recalculate. I've worked at places where this was a timestamp as well. Perhaps not as clean as an id but it allowed us to schedule when the item was executed. As a queue feature this is somewhat of an antipattern but did make it clean to implement exponential backoff within the framework itself.

Right but in this "100-engineer" scenario you'd have hoped the following would have happened:

- Docs and guidelines on migrations would have been written

- Some level of approval and review is required before execution

These are things that isn't really postgres specific, any company that doesn't have those is going to be a nightmare.

Also: Will your implementation fall over if there's a long running transaction that stops vacuum from removing tuples?