Or a small step that enables actually problematic real compliance, combined with a bad precedent: a "secure" way to populate that birth date field is a plausible future drive-by contribution.

There is a line of reasoning out there that giving every system a different birthdate, and trying to fill it with as much false information as possible, is one way of balancing the scales. I'm not sure how useful it is, kind of like when a website asked for your age and you just put in whatever.

Why didn't systemd reject these changes? Was there an internal debate that the article doesn't cover, or is it the arbitrary decision of other "volunteers"?

As I understand it, anyone with commit permissions can commit a PR, no matter what the community or even other devs think. So, no debate. Just commit and that's it. I don't even remember ever seeing a "block commit" setting or something that would prevent commiting a PR before discussion takes place and "block commit" is lifted.

Anyway, the discussion is pointless. Poettering approved. He probably would have commited the PR himself if he saw it in time.

So it depends. Float parsing performance is only a problem if you parse many floats, and lazy access might reduce work significantly (or add overhead: it depends).

Exactly. My for use cases, this format is amazing. I have very few floats, but lots and lots of objects, arrays and strings with moderate levels of duplication and substring duplication. My data is produced in a build and then read in thousands or millions of tiny queries that lookup up a single value deep inside the structure.

rx works very well as a kind of embedded database like sqlite, but completely unstructured like JSON.

Also I'm working on an extension that makes it mutable using append-only persistent data structures with a fixed-block caching level that is actually a pretty good database.

As an example of the likely future of science in the USA, read about Trofim Lysenko.

What things to learn are more important for "engineers" than using VC messages and history for communicating adequately (including communicating with themselves in the future) and using VC merging, staging etc. to put source code in a good state that they intend to build, share and archive? Irreproducible or incomprehensible work is worse than nothing.

That’s akin to saying the most important thing for an author is to use a word professor correctly.

I'd argue its like saying its important for an author to write an entire book using ed.

This is naive pathfinding that adopts the shortcut of perfect information. Good looking pathfinding simulates realistic terrain ignorance (no "psychic powers"), but it is likely to be expensive enough to require other compromises (e.g. updating paths less often).

You reckon the perfect information version is cheaper than an algorithm that works only on the tiles near to the unit? But this quickly gets too complicated to discuss; there's the confusing matter of precalculation versus live updating.

The perfect information version calculates the path once on click, the local version needs to recalculate every time the unit moves (and new tiles are "seen")

Recalculating the path every game tick is too expensive. What brood war did was to just have units wait for a second when they collide with something before recalculating the path. This resulted in horrendous "traffic jams".

It's also why Brood War players got into the habit of spam-clicking, because the game would recompute paths every time you issued a command, so spam-clicking resulted in smoother movement.

Neither deadlines nor cheap work for hire help any sort of review process, while an hobby project is normally done by someone who cares.

> "everything is moving very fast"

Then slow down.

With this objective lack or control, sooner or later your LLM experiments in production will drive into a wall instead of hitting a little pothole like this diagram.

And at the same time, they have time to quickly brush it off with "looks like a vendor" even though people are still investigating. Yes, we can see it's moving really fast, probably "move fast break things" been infecting Microsoft, users are leaving Microsoft behind because everything is breaking then clueless VPs blame it on moving too fast?

- Put on your seatbelts, man!

- I can't, moving too fast!

"Driving into a wall" is still a positive outcome. It's just as likely to drive into a crowd.

Serious loss of life is a plausible LLM outcome, particularly for Microsoft who does both operating systems (incidents can be much worse than the Crowdstrike bricking) and chatbot assistants that can offer lethal advice. Catastrophic property damage is hopefully more likely.

Jokes on you, I’ll cash out by then and move to the next gig.

Powerful, "capable" plugins are obvious; NSA cannot stop people from writing them, and they have little reason to restrict their use.

I think what NSA is likely to keep confidential are in-house plugins that are so specialized and/or underengineered that their publication would give away confidential information: stolen and illegitimate secrets (e.g. cryptographic private keys from a game console SDK), or exploits that they intend to deny knowledge of and continue milking, or general strategies and methods (e.g. a tool to "customize" UEFI images, with the implication that they have means to install them on a victim's computer).

Generally, the nth roots of 1 form a cyclic group (with complex multiplication, i.e. rotation by multiples of 2pi/n).

One of the roots is 1, choosing either adjacent one as a privileged group generator means choosing whether to draw the same complex plane clockwise or counterclockwise.