blackenedgem

See https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...

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.

The funny thing is Firefox already perfected this feature years ago with Panorama. Then one day decided to remove it because "less than 1% of users use it" (https://news.softpedia.com/news/firefox-45-will-drop-tab-gro...)

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.

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.

You may want to watch this if Surely You're Joking read years ago is your main reference point: https://youtu.be/TwKpj2ISQAc

>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?

No but it does have the concept of tablespaces. If you want you can map RAM to a disk location, set that up as a tablespace, then tell postgres to use that tablespace for your given table. Also set the table as UNLOGGED while you're at it.

A bit more work yes that could be simplified, but fully supported if you control the stack.

Intel was right on their EUV assessment though and did invest early. Early EUV had terrible throughput and wasn't at all viable for mass production.

TSMC's 7nm where they jumped ahead of Intel used quad-patterning DUV which is also what Intel was trying. TSMC only started to introduce EUV at 6nm and 5nm which is when ASML had made great breakthroughs and vastly increased WPH. And even then EUV was only used sparingly at the most critical layers. Because other problems were still being solved like uptime and compatible pellicles.

If you want to blame Intel's decisions then look at their use of cobalt contacts or COAG use. They tried to do too much at 10nm when shrinks were getting harder.

I'm enjoying the replys to this not getting that it's a joke

An awful lot of free student access programs revolve around the uni email address being accredited. Foe example Jetbrains will give you a full version of their products if you register with a uni email, then require you to verify it yearly.

If you forward emails automatically then you'd lose this accreditation. I suppose the solution would be an accreditatiom domain that forwards to your uni address only, but that's extra work now.

Stormcow

I think the problem you'll eventually run into is figuring out intent from the diff. It seems like an easier version of reverse compiling.

When it comes down to semantic diffs I'm more interested in something like the Semantic Patch Language by Coccinelle. Being able to represent mundane refactorings across an entire codebase in a few lines seems great. And it unifies intent with the diff.

You can start the sequence at -2b, or wrap it around when it gets close to the signed limit. Hopefully you haven't depended on it not wrapping around by that point.

For queue tables you can even use `CYCLE` to do that automatically.

No they're not, even with a `cache` value of 1. Sequence values are issued at insert rather than commit. A transaction that commits later (which makes all updates visible) can have an earlier value than a previous transaction.

This is problematic if you try to depend on the ordering. Nothing is stopping some batch process that started an hour ago from committing a value 100k lower than where you thought the sequence was at. That's an extreme example but the consideration is the same when dealing with millisecond timeframes.

Yeah pretty much, although ids can still be a little better. The big problem for us is that we need the security of UUIDs not leaking information and so v7 isn't appropriate.

We do use a custom uuid generator that uses the timestamp as a prefix that rotates on a medium term scale. That ensures we get some degree of clustering for records based on insertion time, but you can't go backwards to figure out the actual time. It's still a problem when backfilling and is more about helping with live reads.

It's not even necessarily it being strictly monotonic. That part does help though as you don't need to skip rows.

For me the bigger thing is the randomness. A uid being random for a given row means the opposite is true; any given index entry points to a completely random heap entry.

When backfilling this leads to massive write amplification. Consider a table with rows taking up 40 bytes, so roughly 200 entries per page. If I backfill 1k rows sorted by the id then under normal circumstances I'd expect to update 6-7 pages which is ~50kiB of heap writes.

Whereas if I do that sort of backfill with a uid then I'd expect to encounter each page on a separate row. That means 1k rows backfilled is going to be around 8MB of writes to the heap.

Because it's much better for range queries and joins. When you inevitably need to take a snapshot of the table or migrate the schema somehow you'll be wishing you had something else other than a UUID as the PK.

I find average leaf density to be the best metric of them all. Most btree indexes with default settings (fill factor 90%) will converge to 67.5% leaf density over time. So anything below that is bloated and a candidate for reindexing.

Because there's a good chance down the line you will need to do some sort of range query. Let's say you want to add and backill a column. Not too bad, you create a partial index where the column is null and use that for backfilling data.

But at a certain scale that starts taking too long and a bigint column would be quicker. Or you decide you need to periodically scan the table in batches for some reason. Perhaps to export the contents to a data warehouse as part of an initial snapshot.

You can skip enumerating these possibilities by having a bigint surrogate key from the get go. There's other advantages as well like better joins and temporal locality when the bigint index can be used rather than the uuid.

That's all well and good until something goes down and you need someone knowledgeable to diplomatically shout at a vendor.

It's not really the UK regulator's fault though, if anything they were the best as they gave their response first (a provisional no). The EU was still investigating and the US DOJ was also preparing similar investigations. The CMA also provided Adobe with a list of changes they could make in order for the application to be approved, so it's not even like they were unwilling to entertain it.

As we saw with the Blizzard acquisition the UK CMA will bend to international pressure if it's the only one holding out.