At least in Mexico your government ID is nothing private or confidential. Basically anyone can determine anyone else's ID with vastly publicly available information.

Unlike the US your ID is just an ID and not a form of secret or authentication token.

Do those design practices protect you when you apply a refactor and now you don't know which call sites may be broken now?

Yes

I've commented about this before.

The answer is development branches are forbidden but releases still use a kind of branching approach.

When you make a release you use commit A from main, then development continues, commit B adds a feature, and maybe commit C fixes a serious bug.

You don't want to make a new release at C because it includes new non tested features, instead you cherry-pick fixes to your release, test the new release candidates, and release that when ready.

Development still happens in main however.

Another big tool to minimise these problems is to separate the concept of feature release from the concept of binary release. You don't have to make a true deployment to release new features or roll them back, just use a toggle switch.

You still need a bootloader to run the Linux kernel.

well, not with efistub, at least, depending on how you define bootloader.

With efistub, isn't the built-in EFI firmware the bootloader?

I prefer the Gerrit workflow over any other git-based workflow, specially since it seems to be going the Jujutsu route in the future: https://www.gerritcodereview.com/design-docs/support-jujutsu...

The "preview" and "code" buttons in the components break the "alt+arrow" bindings to go back to the previous page. Instead it just alternates between "preview" and "code".

The only real no LLM license is keep your code private, I think it is that easy.

I have to say, it is _extremely_ impressive when a tiktok I watched reminds me of some other tiktok, so I go and search for a very loose description of the tiktok, and the first result is 95% of the time what I wanted to find.

I don't think any single other platform has as good a search feature as TikTok does.

oh wow, you're really lucky. around my friend groups who use tiktok, the main complaint is how bad the search is. unfortunately for us, getting a specific video is almost impossible =(

Thats super interesting (I deleted Tiktok because it was too addicting!), but this is a common complaint about Instagram is that it feels impossible to find a reel based on keywords.

Clone doesn't work when you need to propagate data mutations, which is what you need most of the time.

Another option is to just use cells and treat the execution model similarly to JavaScript where mutation is limited specific scopes.

I never got to test this, but I always wanted to explore in postgres using table partitions to store soft deleted items in a different drive as a kind of archived storage.

I'm pretty sure it is possible, and it might even yield some performance improvements.

That way you wouldn't have to worry about deleted items impacting performance too much.

It's definitely an interesting approach but the problem is now you have to change all your queries and undeleting get more complicated. There are strong trade-offs with almost all the approaches I've heard of.

With partitioning? No you don't. It gets a bit messy if you also want to partition a table by other values (like tenant id or something), since then you probably need to get into using table inheritance instead of the easier declarative partitioning - but either technique just gives you a single effective table to query.

Pg moves the data between positions on update?

If you are updating the parent table and the partition key is correctly defined, then an update that puts a row in a different partition is translated into a delete on the original child table and an insert on the new child table, since v11 IIRC. But this can lead to some weird results if you're using multiple inheritance so, well, don't.

I believe they were just pointing out that Postgres doesn't do in-place updates, so every update (with or without partitions) is a write followed by marking the previous tuple deleted so it can get vacuumed.

That’s not at all what the child to me was saying in even a generous reading.

But HOT updates are a thing, too.

What do you think they were saying? I don't see any other way to read it.

HOT updates write to the same tuple page and can avoid updating indexes, but it's still a write followed by marking the old tuple for deletion.

> Pg moves the data between positions on update?

I assume they typo'd "partitions" as "positions", and thus the GP comment was the correct reply.

IDK if the different drive is necessary, but yes partitioning on a deleted field would work.

Memory >>>>> Disk in importance.