I have a slightly different view of this history. Instead of: "The history here is that this project was very popular on cloud providers (e.g. AWS calls their offering "Elasticache") and the original authors got pissy that they were being cut out of whatever money was being paid for using their free software. So they changed the license and here we are.", I would say: "... and the original investors got pissy that they were being cut out of whatever money was being paid for using the free software in which they invested, although 70% of it was written by others. So they changed the license, they disbanded the Core Team after the original developer left, and here we are."

Redis was not written by Redis Ltd (the company). It was originally written and released more than 15 years ago by Salvatore Sanfilippo (a.k.a. antirez) who was soon joined by a community of developers who loved this open source in-memory database and started contributing to it. The project was sponsored by VMWare/Pivotal for a while, but in 2015 it was bought by a company that had renamed itself Redis Labs (originally Garantia Data). Under the new ownership, Redis continued being open source but in 2018 some optional modules were converted to the proprietary SSPL license. This caused some controversy but the company promised that the core of Redis would always remain free and open source. This worked for a few years and this even survived the departure of the original developer. The Redis project continued being developed by a community led by a Core Team of developers coming from various companies (the main ones being Madelyn Olson from AWS and Zhao Zhao from Alibaba Cloud).

But last year, things changed even more. The company that had renamed itself again from Redis Labs to Redis Ltd decided to break their 2018 promise and announced that they would release the next version of Redis under a proprietary license. They also decided to disband the Core Team and take complete control over the core of Redis. The former members of the Core Team left the Redis project and moved to the fork that eventually became Valkey. According to Madelyn Olson, 70% of the Redis code was written by people outside Redis Ltd, so this story is rather different from some other projects in which the original developers wanted to stop the evil cloud hyperscalers who were profiting from their code without giving anything back. In the case of Redis, some of the core code was actually written by people paid by those could companies and only a minority of the code was written by Redis Ltd.

Nope. That's why I changed all my players to BlueOS.

The only problem with this is you have to go stand in the sunlight to charge it.

I replaced all my SONOS connects with BlueSound node Nano devices. A pricey replacement, but worth it.

As a bonus I was now able to turn off SMB1 on my home Samba server !

I don't necessarily disagree with where you're going here, but can you elaborate on this:

I've worked at government contractors that had real air-gaps for things like their databases, but that does not seem to be the norm for the rest of the world. How would ordinary businesses make use of their databases if they are not network accessible under any circumstances, printed reports? Some sort of unidirectional transmission? What sort of data ingress are they using?

I ask this because I have been involved in the transfer of data in highly regulated, air-gapped systems, and they are incredibly expensive. Are you really indicating that true air-gap databases will be ubiquitous (or at least commonplace) in the forseeable future?

> Every large NAS vendor (Synology, QNAP, etc) has their own SMB server they wrote themserlves

That's untrue. Both Synology and QNAP use Samba. QNAP contributes code and bugfixes back to samba.org (Hi Jones !).

I'm more interested in Skype vs Zoom...

I'm 50, in UI, and feeling similar.
I don't mind agile per se (but it's difficult to come in on a very established project - so many decisions were made, and you don't even have the full context to judge them properly. It's like learning a new language, basic fluency is hard won)

What I do mind is how much flavor of the month there has been - a lot of complexity and difficulty in following code path for very theoretical gains . Any redux project smells so much like 2019, it's sad.

So like 20+ years ago, Wired declared "free wins".
I think people - after being nickel and literally dimed by 10-cents-per-SMS - were rightfully shy of "pay per transaction", because thy weren't sure what their usage would look like and that shit adds up.

So two decades later we have this sad fork in the road, two main paths:
* "free", but shitty with ads or other ways they figured out how to commoditize your attention
* subscription, where they can keep collecting rent no matter how little you use it.
( with "pay per usage" the third way less traveled)

The upstream Linux kernel doesn't differentiate between security bugs and "normal" bug fixes. So the new kernel.org CNA just assigns CVE's to all fixes. They don't score them.

Look at the numbers from the whitepaper:

"In March 2024 there were 270 new CVEs created for the stable Linux kernel. So far in April 2024 there are 342 new CVEs:"

Yes ! That's exactly the point. Trying to curate and select patches for a "frozen" kernel fails due to the firehose of fixes going in upstream.

And in the kernel many of these could be security bugs. No one is doing evaluation on that, there are simply too many fixes in such a complex code base to check.

Oh that's really sad. I hope they use a more up to date version of Samba :-).

I don't see that argument in the blog or paper.

Did you read them ?

There are many more unfixed bugs in vendor kernels than in upstream. That's what the data shows.

You're missing something.

New bugs are discovered upstream, but the vendor kernel maintainers either aren't tracking, or are being discouraged from putting these back into the "frozen" kernel.

We even discovered one case where a RHEL maintainer fixed a bug upstream, but then neglected to apply it to the vulnerable vendor kernel. So it isn't like they didn't know about the bug. Maybe they just didn't check the vendor kernel was vulnerable.

I'm guessing management policy discouraged such things. It's easier to just ignore such bugs if customer haven't noticed.