> And how is it "minutiae" to be able to figure out "is my database version actually supported"?

Remembering "8.4", "9.7" and ".4" just doesn't seem like a particularly big deal to me. The number* has only changed 3 times in the last 10 years.

So, the stuff that basically appeals to people chasing the AI dragon, and has zero practical use for 99.999% of developers making real products?

> I wish I was joking!

I wish I could care even a little bit about such minutiae.

I'm sure for some shops this will drive them to pay for the same feature in MariaDB cluster, but I'm more likely to just transition to MySQL Group Replication.

This is my whole point about MariaDB - they are steadily making their OSS software completely dependent on the company (paid) versions for anything beyond toy scale.

Given that MariaDB the company is now owned by a private equity firm, I doubt it's going to get better.

Access to source control is required on a developer workstation.

It is not required inside an application environment on that workstation (eg a VM or other such system that both provides a standard environment and creates separation)

I'm not making any claims about the security of react.

If your secrets in a dev environment can actually do any damage if leaked, you're doing something very fucking wrong.

> React's last minor version bump included 100 files and ~5k changes.

So you're choosing over engineered dependencies and then complaining they're too big.

Somehow I think the problem, as usual, started with the meat sack on the chair.

The evidence of course is that when you say "left pad" no one knows what you're referring to because nothing bad ever happened.

> If a package needs an install script to be used, to compile some native code for example, you still need to run the install script before you can use the package.

This already sounds like a giant red fucking flag, but sure whatever, what you're using needs some compile step. You can be in control of what runs when and where. Heck you could even take the fucking maverick solution and compile the shit once out of band and deploy the compiled binary to your production environment. I know that forethought and planning ahead will come as a fucking shock to the NPM using community, but try it some time, it's really kinda good.

> Manually repeating the actions npm does automatically does nothing to protect you from supply chain attacks.

I mean it does, inherently, if you're running those actions locally in an environment without production access...

Oh noes, your compromised module stole your DB credentials, and your SES credentials to spam all your customers..... and just got a bunch of failures or sent messages to no-one because the environment has dummy data and uses a locked down sending configuration for SES.

There is 100% benefit in running that shit in a development environment.

> The only thing that helps is to review code before you run it.

Right, and somehow you think having the code in question literally in your VCS, waiting for a merge like all the other code... that's not apparently helpful.

But hey thanks for proving me right about the unhinged complaints. Stong echoes of "we've tried nothing and we're all out of ideas".

- dependencies "disappearing" (aka left pad 2, electric boogaloo)

- dependencies running nefarious "install scripts" on prod

Apparently some language package managers also will silently install newer versions than a lock file specifies, if you use the wrong install command. So that's arguably more a case of saving you from yourself but the example I saw said that "... install" is wrong you need to use "... ci" which is kind of asinine IMO.

Things like sudden changes in dependencies should also be noticed more readily.

Just a word of warning from someone who's always advocated for this approach:

Prepare to be inundated with ridiculous, nonsensical arguments about why it's impossible to work that way.

Php has had a strict equals operator for decades. You not using it is not a language fault.

For the second point: I doubt you'll fine any language where you can just do an equals comparison on floats and it works as expected. That's the nature of floating point numbers.

Yes because bad drivers aren't representative of all drivers. You also missed the part where laws are changed, safety laws are strengthened.

Oh wait. You're American aren't you.

In most of the world, laws are put in place to protect people. The Cybertruck for example, cannot be legally driven (regardless of not being for sale) in many countries because it doesn't meet pedestrian safety standards.

In my home state it's a finable offence to touch or even have your phone sitting in your lap while driving a car, and they've put detection cameras in place to enforce these laws.

So maybe define who you mean by "we" before claiming that people think kids being mutilated by negligent drivers of either the robotic or fleshy kind, is "good enough".

What happens when a Tesla does the same thing? Besides them lying and hiding information I mean. What remedial action is taken to reduce that specific risk from reoccurring?

The sarcasm was because this suggestion is ridiculous IMO. It's like saying "Tesla refuses to use state-of-the-art LIDAR for their attempts at an autonomous vehicle, therefore I shall only travel in vehicles that have both a driver and a conductor, and are propelled by beasts!".

VSCode being a turd isn't a reason not to use an IDE. It's a reason to use an actual IDE, rather than a glorified text editor, with the aforementioned millions of shonky plugins trying to recreate IDE levels of functionality.

I can assure you I am not.

True developers just scream at the universe and it responds with cosmic radiation that flips the correct bits to form the binary code they intended.

Great stuff champ. Really dispelling the idea that vibe coders have no idea what slop is being churned out. Top marks.