Since the day Oracle bought Sun, we've heard how Oracle is going to kill MySQL, and/or make all its features "enterprise" only.

Both companies have middleware layers for directing queries, but:

- MySQL Proxy/MySQL Router are both GPL2

- MariaDB MaxScale is BSL (it's a product of MariaDB the company, not MariaDB the foundation)

Codership Oy was a company that produced Galera, a plugin for multi-master replication. It was available for the community editions of Oracle MySQL, MariaDB, and integrated via Percona in their build of MySQL to make Percona XtraDB Cluster aka PXC.

MariaDB the company bought Codership Oy last year. Very soon after this happened, the website for Galera started redirecting to MariaDB the company's Enterprise Cluster page with zero mention of the open source project they'd just bought.

Not long after that, they stopped making Galera available for Oracle MySQL, and even removed it from the MariaDB community edition builds. It was to only be available via MariaDB Enterprise edition. They have subsequently taken a minute backstop on the MariaDB Community edition scenario, but it sounds very much like it's "we won't rip it out right now", and essentially the Community edition is likely to have to (try to) support its own internal fork of Galera to keep the functionality.

This is similar to the scenario Percona is now in - supporting their own version of Galera for PXC. The difference is they're a consulting company and have revenue and paid staff to do so. MariaDB the foundation is essentially joined at the hip with MariaDB the company for resources, but they apparently have very different goals.

Literally the only thing the foundation "produces" is the community edition of MariaDB... and they send people for the documentation of said product to MariaDB the company's website. Last year MariaDB the foundation agreed to define and recognise a "Primary Code Contributor" for the project... and it's MariaDB the company.

Case in point: all the people who still loudly say everyone should jump from Oracle owned MySQL to MariaDB, in spite of MariaDB Inc doing practically everything the original MariaDB fork was meant to "protect" users from at the hands of Oracle.

I'm not saying oracle isn't a huge faceless corporation that wants nothing but money. I'm saying that tech people are IME better at following trends than doing real research themselves.

You deserve each other.

I'm not saying it isn't an improvement but this feels like choosing centos because you don't like the direction fedora is taking.

> one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other browsers, and we couldn't keep up

I tried their "local ai autocomplete" thing a few years ago for a little while and it was hot garbage. It guessed the right/acceptable completion about 30% of the time at best.

I haven't looked at it since.

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