stephenr

A lot of people in tech buy every bit into cargo culting and following what they've heard is popular or "what everyone does", without much justification or understanding.

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.

Honestly I don't know which is a bigger scourge on humanity: Google doing Google shit or every company with a fucking IVR.

You deserve each other.

Isn't graphene completely dependent on what Google ships though? Ok they may be able to support Motorola devices longer than Googles releases facilitate supporting Google devices, but it's still ultimately android, which is still ultimately controlled by Google.

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.

... is this meant to be satire? You're familiar with the main storyline yes?

Are you saying that a story where voting is reserved for "some people" is what is needed for a democratic government?

How long ago was this?

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.

I would happily write stored procs using the current language support for a decade without pay, before I'd subject myself to putting javascript in a fucking database engine.

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

> such as vector indexes and JS stored procedures

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.

To me the biggest "unknown" with Percona is that MariaDB (the company) bought out Codership (the creators of Galera Cluster, which XtraDB Cluster is based on) and it doesn't seem to be OSS any more.

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.

The comparison with MySQL/MariaDB is unfortunate, given that since the "split" MariaDB has shown itself to be every bit the corporate owned "FOSS" project while its supporters still harp on about how terrible oracle is for OSS, without actually acknowledging the real history of each respective project and accompanying company.

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

We are clearly talking about different things.

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.

> Most of the recent supply chain attacks specifically target stealing secrets from development environments.

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.

> If you already had left pad cached then you were not affected by its disappearance.

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