Easy replication. I suppose it's faster than Postgres's JSONB, too.

I would rather not use it, but I see that there are legitimate cases where MongoDB or DynamoDB is a technically appropriate choice.

It's mostly RAM allocated per client. E.g. Postgres is very much limited by this fact in supporting massive numbers of clients. Hence pgbouncer and other kinds of connection pooling which allow a Postgres server to serve many more clients than it has RAM to allow connecting.

If your Node app spends vety little RAM per client, it can indeed service a great many of them.

A PHP script that does little more than checking credentials and invoking sendfile() could be adequate for the case of serving small files described in the article.

This particular case, with the numbers given, would work as a server for profile pictures, for instance. Or for package signatures. Or for status pages of a bunch of services (generated statically, since the status rarely changes).

Yes, an RPi4 might be adequate to serve 20k of client requests in parallel, without crashing or breaking too much sweat. You usually want to plan for 5%-10% of this load as a norm if you care about tail latency. But a 20K spike should not kill it.

«Color pixels drain more energy than grayscale ones. Personally found my phone lasting twice as long as before.»

Is this a joke? Is there a real physical effect at play?

I can't imagine. AFAIK no phone has "grayscale" pixels. Grey or white light is achieved by blending the other colors equally.

A true monochrome screen is a thing, but they are for specialized applications and not used in phones.

Maybe power draw is not linear and with grayscale rgb sub-pixels can operate at lower intensity and lower power draw than if the luminance wasn't distributed across all colors?

They said they noticed themselves looking at their phone far less. Most likely this is what saved the power, just a typical spurious correlation and a bad theory for the reason.

some oled displays have white subpixels, i dont know if the power cost is a thing though

...and you would point at a backdoor. (If it is there.)

I'd namedrop Salt Typhoon, but it feels a bit unfair to rely on American SigInt.

Sounds like a faulty SD card.

I have 2 nvmes and i have tried it with several sd card.

A bit less enraged: pre-commit hooks should be pure functions. They must not mutate the files being committed. At best, they should generate a report. At worst, they could reject a commit (e.g. if it contains a private key file included by mistake).

> e.g. if it contains a private key file included by mistake

Thanks - this is the first example of a pre-commit hook that I can see value in.

Remember that such key will be copied into the repository on `git add` already and will stay there until garbage collected.

In my experience pre-commit hooks are most often used to generate a starting commit message.

To put it more bluntly, pre-commit hooks are pre-commit hooks, exactly what it says on the tin. Not linting hooks or checking hooks or content filters. Depending on what exactly you want to do, they may or may not be the best tool for the job.

To put it even more bluntly, if you are trying to enforce proper formatting, pre-commit hooks are absolutely the wrong tool for the job, as hooks are trivially bypassable, and not shared when cloning a repo, by design.

> In my experience pre-commit hooks are most often used to generate a starting commit message.

The `prepare-commit-msg` hook is a better place to do that as it gives the hook some context about the commit (is the user amending an existing commit etc.)

> To put it even more bluntly, if you are trying to enforce proper formatting, pre-commit hooks are absolutely the wrong tool for the job, as hooks are trivially bypassable, and not shared when cloning a repo, by design.

They aren't a substitute for server post-receive hooks but they do help avoid having pushes rejected by the server.

This is awesome.

The way the artists work this very limiting and demanding medium is impressive, and probably not even easily imitated by general-purpose generative models.

You might want to take a look at https://diffusionillusions.com/ . You don't need a specialized models, little bit of traditional code for enforcing constraints on top of general purpose models can do quite a bit.

The key addition to the list: "Uncrewed aircraft systems (UAS) and UAS critical components produced in a foreign country and all communications and video surveillance equipment and services listed in Section 1709(a)(1) of the FY25 National Defense Authorization Act (Pub. L. 118-159)". In other words, drones, motors, batteries, control systems, sensors.

A better abstraction would be a better SDK then.

BTW repetitiveness is not free, it's cognitive load that a developer must deal with. An abstraction is also a bit of cognitive load that grows with the abstraction's complexity; the point is to find a balance that minimizes it.