11 ms·

Valkey Turns One: Community fork of Redis

249 points by cebert 1y ago

bhouston 1y ago
We need to get valkey into the default distro package managers. It sucks having to add keys and update the distro get valkey installed in say a GitHub Action runner.
- yjftsjthsd-h 1y ago
  What distro doesn't have it that you need? Skimming https://repology.org/project/valkey/versions https://repology.org/project/valkey/versions it seems to be in nixpkgs, Arch, Ubuntu, Fedora, Debian, and EPEL. Of those, the only caveat I immediately see is that Debian only got it in 13 or 12+backports.
  - Hasnep 1y ago
    GitHub Actions runners are based on Ubuntu, and from the Repology link it seems ValKey is in the "universe" repository which is a community supported repository and therefore might not be enabled by default.
    - kijin 1y ago
      Redis has always been in universe as well. Most things in Ubuntu are in universe and practically unmaintained. Getting your software into the default package managers is not necessarily the best choice for a new and fast-moving project. You'll be stuck answering bug reports for an ancient version and monkey-patching it for the life of the LTS release. It's much more ergonomic, both for maintainers and users, to run your own PPA or repo with the latest version.
      - b112 1y ago
        For users? Hardly. If you want stable, you want a non-changing branch with security fixes only. No surprises, no api changes, no config file changes. And you don't want to be stuck on a non-security fix version. You cannot sit on the same version without tracking security, while you slowly retool and recode for breaking api/behaviour changes. Debian stable has redis, and others, and will see backported security updates for the life of the support window. This isn't just about redis. If you're doing this with anything, you must track secuirty updates, must stay up to date, or you are negligent. And tracking changes for infra stuff like redis, and other backend stuff is a waste of resources with typically zero benefit. I won't touch core daemons like redis, if it isn't distro maintained. I have better things to do. More important things to worry about.
        kijin 1y ago
        You're right about Debian. Ubuntu is a different story. You're probably better off using an alternative repository for anything important that you find in the "universe" repo. That stuff is not "distro-maintained" at all. Case in point: there are known vulnerabilities in the version of Redis shipped with Ubuntu 22.04 LTS, which a lot of people would assume is still maintained. But Redis is in universe, so patches are only available for those with an Ubuntu Pro subscription.
        b112 1y ago
        Debian's contrib and non-free are similar, only 'main' is rigorously shepherded.
        kijin 1y ago
        Only a small number of packages in Debian belong in contrib and non-free. Redis is safely in main. Ubuntu throws 90% of its packages in universe and doesn't even bother to pull security fixes from Debian. It's absolutely irresponsible and not comparable to Debian at all.
    - motorest 1y ago
      > GitHub Actions runners are based on Ubuntu (... That sounds like a GitHub Actions problem. GitHub Actions only offers a very limited set of container images, and for Ubuntu they just go with the LTS version that shipped before Valkey even existed. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#standard-github-hosted-runners-for-public-repositories https://docs.github.com/en/actions/writing-workflows/workflo...
      - Kwpolska 1y ago
        You can use any Docker container to run your Actions.
    - skywhopper 1y ago
      Then the Redis that’s packaged for those versions of Ubuntu will be the BSD version... which is just an older version of Valkey.
  - bhouston 1y ago
    [flagged]
    - nothrabannosir 1y ago
      Good lesson in when not to use chatgpt. $ docker run --rm -ti debian:trixie root@d12c52dcfee8:/# apt-get update && apt-get install -y valkey Get:1 http://deb.debian.org/debian trixie InRelease [178 kB] ... root@d12c52dcfee8:/# valkey-server --version Valkey server v=8.1.1 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=13683752e517a7b6
      - bhouston 1y ago
        Claude gives similarly complex answers for the same question with regards to valkey but simple solutions for redis: https://claude.ai/share/ba9ecc54-5f21-4ec5-ab36-88e8eac38d1a https://claude.ai/share/ba9ecc54-5f21-4ec5-ab36-88e8eac38d1a
        MaKey 1y ago
        It seems like it went over your head that the package name is valkey, not valkey-server, so the instructions won't work. Why paste a long faulty AI response instead of linking to the concise official documentation? https://valkey.io/topics/installation/ https://valkey.io/topics/installation/
        accoil 1y ago
        URLs also don't resolve
        satvikpendem 1y ago
        You're missing the point. LLMs aren't the source of truth, the docs are.
        deleted 1y ago
        [deleted]
- LukeShu 1y ago
  FWIW, valkey has replaced redis in Arch Linux.
  - jdmarble 1y ago
    And will in RHEL 10, too!
- hnarn 1y ago
  If the first thing you do in CI is adding a bunch of stuff to the container image you just pulled, you should probably make your own image.
bofaGuy 1y ago
I run Redis across dozens of applications. So when Valkey became available for a discounted price on AWS I was excited. We finally got around to trying it out about 2 months ago and all was going well. No noticeable difference in performance. Until Valkey just died. It died in such a way that AWS still thought it was running happily but it was completely offline. It took 12+ hours for it to come up again and then it happened again... AWS researched the issue for 2 weeks and couldn't figure it out. It will be a long time before we attempt to use Valkey for anything critical in the future. We since have replace that Valkey with Redis under the same workload and have no issues.
- sampullman 1y ago
  Could that be an AWS operational issue, and not related to Valkey? I only run redis myself but wouldn't immediately place blame on Valkey if that happened.
  - ummonk 1y ago
    Yeah I don't understand how something could be "completely offline" and still have health checks passing.
    - perfectra1n 1y ago
      “Completely offline” and passing health checks don’t typically go together…
    - motorest 1y ago
      "completely offline" also doesn't sound like a problem with a software project. At best it's a particular managed service experiencing downtime. Would Linux be to blame if my power supply goes up in smoke?
    - Aeolun 1y ago
      Can’t be reached outside the network that the instance and health check are running on? Maybe available in one AZ, but not on the one that’s trying to connect.
nwlotz 1y ago
I'm curious, why hasn't Valkey picked up corporate sponsors to the degree OpenTofu did when HashiCorp changed Terraform's licensing? I just haven't seen a meaningful level of reaction compared to the community outcry when Hashi changed to BSL.
- apgwoz 1y ago
  Probably because Terraform’s value was always the community of providers and modules, and that was in danger. Where as, Redis/Valkey’s ecosystem exists mainly as advocacy and happy users. It might be central to an architecture, sure, but using a previously open sourced version was unlikely to cause considerable problems. Contrast to potential huge changes to the BUSL’d terraform that create incompatibility with existing providers would lock you in to HashiCorp’s new, unfavorable, terms.
  - sofixa 1y ago
    > Probably because Terraform’s value was always the community of providers and modules, and that was in danger. It was never in danger, the providers remained under MPL and were explicitly excluded from the licensing change, with a good associated explanation (most of them were developed by and with partners and the community, unlike Terraform core which was almost entirely HashiCorp).
    - apgwoz 1y ago
      The providers need a “driver.” Without that, they aren’t very useful as is. That’s the danger. (Yes, pulumi, etc) Additionally, HashiCorp changed the terms of service on the registry, making it only acceptable to use the official terraform binaries to download modules or providers. Now, the providers are mostly open source, so, it was never impossible to recreate the thing—just work. But the point here is that Hashicorp took steps that caused the community of terraform users to recognize that closing off the ecosystem would have a tremendous impact on devops. That’s why there was so much outrage and immediate action taken.
      - 1y ago
linotype 1y ago
So glad this happened and is still going strong. RIP Redis (hopefully soon).
- echelon 1y ago
  Yes, making money is bad. Open source is only in service of the monopolies. Only AWS and the hyperscalers deserve to make millions from Redis. Screw the Redis authors and maintainers. Lesson to all DB startups: fair source your license. Put in anti-hyperscaler clauses into your licenses to preserve your ability to make money and be sustainable. You can let your customers have unlimited access to your code, but stamp out the ability for AWS or Google to offer managed versions. They need to pay you. Don't be Redis or Elasticsearch. For them it's too late. They went uber permissive and now their fate is sealed. They're hundred million dollar cash cows for the giants, and the main committers see none of that.
  - sneak 1y ago
    No, nonfree licenses are bad. Nobody has any issue with people making money with free software. We have issue with people not respecting software freedoms. You seem to be intentionally conflating the two things. Why make source available at all if you are just going to release proprietary software? It’s open source cosplay at that point. Just make commercial proprietary software like a normal software company; don’t pretend you are open source just because your source code is readable on GitHub.
    - aloha2436 1y ago
      > Why make source available at all if you are just going to release proprietary software? Because there's years between one decision and the other, and in that time it turned out that because the software was open source they were structurally disadvantaged versus large cloud providers in being able to make money from it. It seems disingenuous to suggest that the open sourcing was in bad faith given it happened years and paradigms apart from the closed sourcing, even though I don't agree with the decision either.
geerlingguy 1y ago
Didn't antirez announce Redis was going (actual) open source again? https://antirez.com/news/151 https://antirez.com/news/151 If so, is it too little, too late, to turn back the tide? I remember Node.js almost fell apart after the short-lived Io.js fork era, but the community patched up. Is the same possible with Redis? I used to use it a lot, but haven't for the past few years, so I'm not able to get the same perspective on the community around these two projects.
- motorest 1y ago
  > If so, is it too little, too late, to turn back the tide? I think so too. At least to me the Redis rug pull forced Redis to be completely out of the picture, and moving forward valkey is the default option. Fool me once, shame on you.
  - matsemann 1y ago
    I honestly think most people don't care. Yes, a HN bubble care, and might influence what a company chooses. But most people will just reach for Redis by default, none the wiser of all the drama in some small circles.
    - Kwpolska 1y ago
      Linux distros can help pick a winner. If installing Valkey is just `apt install valkey`, but Redis requires compilation/extra repos to get going, people will just choose Valkey. See also: MariaDB.
      - gkbrk 1y ago
        Or better, if installing valkey is both `apt install valkey` and also `apt install redis`. Which is exactly what some distros are doing.
      - fnord123 1y ago
        Is there a useful metric to see if that's really the case? Using the distos package manager means you're at the mercy of the packager for getting new versions. Docker is just as easy and doesn't suffer from this. And building from source gives you full control. Even when using test services, using docker works best since all the Devs will be on the same version instead of splitting between Debian, fedora, and brew versions.
kamikazechaser 1y ago
As usual, I expect some GPL FUD. Here is a good explainer on it. https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-not-restrictive.html https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-no...
- TheBicPen 1y ago
  The argument in the post that copyleft licenses are freer seems handwavy at best. In a literal sense, obligations are restrictions on freedom, so yes, copyleft licenses are less free than permissive ones. Whether or not the overall benefits of said obligations outweigh their restrictions on freedom is a question worth discussing, but it's irrelevant to the question of which style of license is freer.
y2244 1y ago
Now that Redis have u-turned, is it not worth Valkey and Redis having a chat and seeing if they can merge and combine their efforts?
- paulryanrogers 1y ago
  It's not really a U-turn because they haven't returned to their original license. More of a tack by moving to AGPL.
  - pabs3 1y ago
    They didn't move to the AGPL, just added it as an option on the side.
pipes 1y ago
Recently a number of dotnet projects have gone commercial. It feels like a rug pull. I guess it is damaging for other open source dot net libraries because developers are less likely to adopt them, ie it becomes harder to get traction.
- debugnik 1y ago
  In the particular case of .NET, that's not a recent thing. .NET businesses have always been adjacent to freeware/open-core.
  - pipes 1y ago
    I can't remember any libraries that started completely open source and free then suddenly becoming pay only. Though to be fair for some reason early in my career I didn't pay much attention to 3rd party libraries. Maybe because nuget hadn't been invented yet! :)
antirez 1y ago
I'm happy ValKey did great work in the area of I/O threading, and we started to incorporate the most interesting changes recently: a big thank you to all the ValKey contributors that did great work. However, this article is a bit misleading: >Antirez’s emphasis on a shared nothing architecture has been foundational for Redis. Nevertheless, as early as 2020, Redis added support for I/O threads. Unfortunately, they did not offer drastic improvement until recently. If you have previously tried and discarded I/O threads, it is time to evaluate again! Please note that is that same Antirez that implemented I/O threading in 2020, exactly because it does not violate the same reasons why I believe in shared nothing. <technical background> What I/O threading does, is, when we return from the event loop, to recognized that write(2) / read(2) syscalls are very slow, and in that moment we have zero contention, so what about parallelizing in N threads just that I/O, and returning single threaded immediately after? So I implemented this system, and the ValKey folks did the awesome job of making it better (thanks again). </technical background> But it is not true that the system didn't work back then, even if now it was improved, as you can see from the graph in the article itself... I wonder if those posts are payed by somebody or what. There are similar non-sensical posts in the Redis side as well, and they suck likewise, blabling about random things. WTF... What a disservice is this kind of journalism. Anyway, one reason why these stuff are interesting mostly for Redis the company itself, Amazon, Google, and only marginally for normal Redis users, that is in turn the reason why the feature is not so used, is that if you don't have many users in the same machine or you don't see extremely high loads in specific circumstances, you usually don't need to enable it. Many users of Redis, even big users (I remember the numbers of a few very popular social networks) have their Redis CPU usages low enough to don't bother. Btw about threads, there are times when they simply fit. If you see my latest work at Redis, the new vector set data type, well, queries are threaded by default, and you can even use VADD (so writing to a vector set) in a threaded way. Why I changed my mind? Because HNSWs are the first data structures with huge constant times, Redis never had something like that, and this changed the design space that was worth considering. So in 2020 I was already positive about threads, in the past I already had implemented the threaded support for moduels operation, and now vector sets are threaded. It is not about being pro or against, it depends.
- christophilus 1y ago
detail_orient 1y ago
I had heard about Valkey last year and am glad is going strong!
secondcoming 1y ago
Does Valkey provide their own client library? We use Redis all over on GCP both via MemoryStore and on custom machines. We use both classic Redis and Redis Cluster. The official C library is sadly quite deficient if you want to use Redis Cluster and then TLS. We have to use an unofficial hiredis-cluster client [0]. It's a real pain for us. We're considering moving to Scylla. GCP's Memorystore is a joke too. [0] https://github.com/Nordix/hiredis-cluster https://github.com/Nordix/hiredis-cluster
- michael_grunder 1y ago
  Yes, there is a combined fork of hiredis and hiredis-cluster called libvalkey. It is maintained by many of the same people who have maintained hiredis and hiredis-cluster. https://github.com/valkey-io/libvalkey https://github.com/valkey-io/libvalkey

249 points by cebert 1y ago

We need to get valkey into the default distro package managers. It sucks having to add keys and update the distro get valkey installed in say a GitHub Action runner.

yjftsjthsd-h 1y ago
What distro doesn't have it that you need? Skimming https://repology.org/project/valkey/versions https://repology.org/project/valkey/versions it seems to be in nixpkgs, Arch, Ubuntu, Fedora, Debian, and EPEL. Of those, the only caveat I immediately see is that Debian only got it in 13 or 12+backports.
- Hasnep 1y ago
  GitHub Actions runners are based on Ubuntu, and from the Repology link it seems ValKey is in the "universe" repository which is a community supported repository and therefore might not be enabled by default.
  - kijin 1y ago
    Redis has always been in universe as well. Most things in Ubuntu are in universe and practically unmaintained. Getting your software into the default package managers is not necessarily the best choice for a new and fast-moving project. You'll be stuck answering bug reports for an ancient version and monkey-patching it for the life of the LTS release. It's much more ergonomic, both for maintainers and users, to run your own PPA or repo with the latest version.
    - b112 1y ago
      For users? Hardly. If you want stable, you want a non-changing branch with security fixes only. No surprises, no api changes, no config file changes. And you don't want to be stuck on a non-security fix version. You cannot sit on the same version without tracking security, while you slowly retool and recode for breaking api/behaviour changes. Debian stable has redis, and others, and will see backported security updates for the life of the support window. This isn't just about redis. If you're doing this with anything, you must track secuirty updates, must stay up to date, or you are negligent. And tracking changes for infra stuff like redis, and other backend stuff is a waste of resources with typically zero benefit. I won't touch core daemons like redis, if it isn't distro maintained. I have better things to do. More important things to worry about.
      - kijin 1y ago
        You're right about Debian. Ubuntu is a different story. You're probably better off using an alternative repository for anything important that you find in the "universe" repo. That stuff is not "distro-maintained" at all. Case in point: there are known vulnerabilities in the version of Redis shipped with Ubuntu 22.04 LTS, which a lot of people would assume is still maintained. But Redis is in universe, so patches are only available for those with an Ubuntu Pro subscription.
        b112 1y ago
        Debian's contrib and non-free are similar, only 'main' is rigorously shepherded.
        kijin 1y ago
        Only a small number of packages in Debian belong in contrib and non-free. Redis is safely in main. Ubuntu throws 90% of its packages in universe and doesn't even bother to pull security fixes from Debian. It's absolutely irresponsible and not comparable to Debian at all.
  - motorest 1y ago
    > GitHub Actions runners are based on Ubuntu (... That sounds like a GitHub Actions problem. GitHub Actions only offers a very limited set of container images, and for Ubuntu they just go with the LTS version that shipped before Valkey even existed. https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#standard-github-hosted-runners-for-public-repositories https://docs.github.com/en/actions/writing-workflows/workflo...
    - Kwpolska 1y ago
      You can use any Docker container to run your Actions.
  - skywhopper 1y ago
    Then the Redis that’s packaged for those versions of Ubuntu will be the BSD version... which is just an older version of Valkey.
- bhouston 1y ago
  [flagged]
  - nothrabannosir 1y ago
    Good lesson in when not to use chatgpt. $ docker run --rm -ti debian:trixie root@d12c52dcfee8:/# apt-get update && apt-get install -y valkey Get:1 http://deb.debian.org/debian trixie InRelease [178 kB] ... root@d12c52dcfee8:/# valkey-server --version Valkey server v=8.1.1 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=13683752e517a7b6
    - bhouston 1y ago
      Claude gives similarly complex answers for the same question with regards to valkey but simple solutions for redis: https://claude.ai/share/ba9ecc54-5f21-4ec5-ab36-88e8eac38d1a https://claude.ai/share/ba9ecc54-5f21-4ec5-ab36-88e8eac38d1a
      - MaKey 1y ago
        It seems like it went over your head that the package name is valkey, not valkey-server, so the instructions won't work. Why paste a long faulty AI response instead of linking to the concise official documentation? https://valkey.io/topics/installation/ https://valkey.io/topics/installation/
        accoil 1y ago
        URLs also don't resolve
      - satvikpendem 1y ago
        You're missing the point. LLMs aren't the source of truth, the docs are.
      - deleted 1y ago
        [deleted]
LukeShu 1y ago
FWIW, valkey has replaced redis in Arch Linux.
- jdmarble 1y ago
  And will in RHEL 10, too!
hnarn 1y ago
If the first thing you do in CI is adding a bunch of stuff to the container image you just pulled, you should probably make your own image.

bofaGuy 1y ago

I run Redis across dozens of applications. So when Valkey became available for a discounted price on AWS I was excited. We finally got around to trying it out about 2 months ago and all was going well. No noticeable difference in performance. Until Valkey just died. It died in such a way that AWS still thought it was running happily but it was completely offline. It took 12+ hours for it to come up again and then it happened again... AWS researched the issue for 2 weeks and couldn't figure it out. It will be a long time before we attempt to use Valkey for anything critical in the future. We since have replace that Valkey with Redis under the same workload and have no issues.

sampullman 1y ago
Could that be an AWS operational issue, and not related to Valkey? I only run redis myself but wouldn't immediately place blame on Valkey if that happened.
- ummonk 1y ago
  Yeah I don't understand how something could be "completely offline" and still have health checks passing.
  - perfectra1n 1y ago
    “Completely offline” and passing health checks don’t typically go together…
  - motorest 1y ago
    "completely offline" also doesn't sound like a problem with a software project. At best it's a particular managed service experiencing downtime. Would Linux be to blame if my power supply goes up in smoke?
  - Aeolun 1y ago
    Can’t be reached outside the network that the instance and health check are running on? Maybe available in one AZ, but not on the one that’s trying to connect.

nwlotz 1y ago

I'm curious, why hasn't Valkey picked up corporate sponsors to the degree OpenTofu did when HashiCorp changed Terraform's licensing? I just haven't seen a meaningful level of reaction compared to the community outcry when Hashi changed to BSL.

apgwoz 1y ago
Probably because Terraform’s value was always the community of providers and modules, and that was in danger. Where as, Redis/Valkey’s ecosystem exists mainly as advocacy and happy users. It might be central to an architecture, sure, but using a previously open sourced version was unlikely to cause considerable problems. Contrast to potential huge changes to the BUSL’d terraform that create incompatibility with existing providers would lock you in to HashiCorp’s new, unfavorable, terms.
- sofixa 1y ago
  > Probably because Terraform’s value was always the community of providers and modules, and that was in danger. It was never in danger, the providers remained under MPL and were explicitly excluded from the licensing change, with a good associated explanation (most of them were developed by and with partners and the community, unlike Terraform core which was almost entirely HashiCorp).
  - apgwoz 1y ago
    The providers need a “driver.” Without that, they aren’t very useful as is. That’s the danger. (Yes, pulumi, etc) Additionally, HashiCorp changed the terms of service on the registry, making it only acceptable to use the official terraform binaries to download modules or providers. Now, the providers are mostly open source, so, it was never impossible to recreate the thing—just work. But the point here is that Hashicorp took steps that caused the community of terraform users to recognize that closing off the ecosystem would have a tremendous impact on devops. That’s why there was so much outrage and immediate action taken.
    - 1y ago

linotype 1y ago

So glad this happened and is still going strong. RIP Redis (hopefully soon).

echelon 1y ago
Yes, making money is bad. Open source is only in service of the monopolies. Only AWS and the hyperscalers deserve to make millions from Redis. Screw the Redis authors and maintainers. Lesson to all DB startups: fair source your license. Put in anti-hyperscaler clauses into your licenses to preserve your ability to make money and be sustainable. You can let your customers have unlimited access to your code, but stamp out the ability for AWS or Google to offer managed versions. They need to pay you. Don't be Redis or Elasticsearch. For them it's too late. They went uber permissive and now their fate is sealed. They're hundred million dollar cash cows for the giants, and the main committers see none of that.
- sneak 1y ago
  No, nonfree licenses are bad. Nobody has any issue with people making money with free software. We have issue with people not respecting software freedoms. You seem to be intentionally conflating the two things. Why make source available at all if you are just going to release proprietary software? It’s open source cosplay at that point. Just make commercial proprietary software like a normal software company; don’t pretend you are open source just because your source code is readable on GitHub.
  - aloha2436 1y ago
    > Why make source available at all if you are just going to release proprietary software? Because there's years between one decision and the other, and in that time it turned out that because the software was open source they were structurally disadvantaged versus large cloud providers in being able to make money from it. It seems disingenuous to suggest that the open sourcing was in bad faith given it happened years and paradigms apart from the closed sourcing, even though I don't agree with the decision either.

geerlingguy 1y ago

Didn't antirez announce Redis was going (actual) open source again? https://antirez.com/news/151 https://antirez.com/news/151 If so, is it too little, too late, to turn back the tide? I remember Node.js almost fell apart after the short-lived Io.js fork era, but the community patched up. Is the same possible with Redis? I used to use it a lot, but haven't for the past few years, so I'm not able to get the same perspective on the community around these two projects.

motorest 1y ago
> If so, is it too little, too late, to turn back the tide? I think so too. At least to me the Redis rug pull forced Redis to be completely out of the picture, and moving forward valkey is the default option. Fool me once, shame on you.
- matsemann 1y ago
  I honestly think most people don't care. Yes, a HN bubble care, and might influence what a company chooses. But most people will just reach for Redis by default, none the wiser of all the drama in some small circles.
  - Kwpolska 1y ago
    Linux distros can help pick a winner. If installing Valkey is just `apt install valkey`, but Redis requires compilation/extra repos to get going, people will just choose Valkey. See also: MariaDB.
    - gkbrk 1y ago
      Or better, if installing valkey is both `apt install valkey` and also `apt install redis`. Which is exactly what some distros are doing.
    - fnord123 1y ago
      Is there a useful metric to see if that's really the case? Using the distos package manager means you're at the mercy of the packager for getting new versions. Docker is just as easy and doesn't suffer from this. And building from source gives you full control. Even when using test services, using docker works best since all the Devs will be on the same version instead of splitting between Debian, fedora, and brew versions.

kamikazechaser 1y ago

As usual, I expect some GPL FUD. Here is a good explainer on it. https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-not-restrictive.html https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-no...

TheBicPen 1y ago
The argument in the post that copyleft licenses are freer seems handwavy at best. In a literal sense, obligations are restrictions on freedom, so yes, copyleft licenses are less free than permissive ones. Whether or not the overall benefits of said obligations outweigh their restrictions on freedom is a question worth discussing, but it's irrelevant to the question of which style of license is freer.

y2244 1y ago

Now that Redis have u-turned, is it not worth Valkey and Redis having a chat and seeing if they can merge and combine their efforts?

paulryanrogers 1y ago
It's not really a U-turn because they haven't returned to their original license. More of a tack by moving to AGPL.
- pabs3 1y ago
  They didn't move to the AGPL, just added it as an option on the side.

pipes 1y ago

Recently a number of dotnet projects have gone commercial. It feels like a rug pull. I guess it is damaging for other open source dot net libraries because developers are less likely to adopt them, ie it becomes harder to get traction.

debugnik 1y ago
In the particular case of .NET, that's not a recent thing. .NET businesses have always been adjacent to freeware/open-core.
- pipes 1y ago
  I can't remember any libraries that started completely open source and free then suddenly becoming pay only. Though to be fair for some reason early in my career I didn't pay much attention to 3rd party libraries. Maybe because nuget hadn't been invented yet! :)

antirez 1y ago

I'm happy ValKey did great work in the area of I/O threading, and we started to incorporate the most interesting changes recently: a big thank you to all the ValKey contributors that did great work. However, this article is a bit misleading: >Antirez’s emphasis on a shared nothing architecture has been foundational for Redis. Nevertheless, as early as 2020, Redis added support for I/O threads. Unfortunately, they did not offer drastic improvement until recently. If you have previously tried and discarded I/O threads, it is time to evaluate again! Please note that is that same Antirez that implemented I/O threading in 2020, exactly because it does not violate the same reasons why I believe in shared nothing. <technical background> What I/O threading does, is, when we return from the event loop, to recognized that write(2) / read(2) syscalls are very slow, and in that moment we have zero contention, so what about parallelizing in N threads just that I/O, and returning single threaded immediately after? So I implemented this system, and the ValKey folks did the awesome job of making it better (thanks again). </technical background> But it is not true that the system didn't work back then, even if now it was improved, as you can see from the graph in the article itself... I wonder if those posts are payed by somebody or what. There are similar non-sensical posts in the Redis side as well, and they suck likewise, blabling about random things. WTF... What a disservice is this kind of journalism. Anyway, one reason why these stuff are interesting mostly for Redis the company itself, Amazon, Google, and only marginally for normal Redis users, that is in turn the reason why the feature is not so used, is that if you don't have many users in the same machine or you don't see extremely high loads in specific circumstances, you usually don't need to enable it. Many users of Redis, even big users (I remember the numbers of a few very popular social networks) have their Redis CPU usages low enough to don't bother. Btw about threads, there are times when they simply fit. If you see my latest work at Redis, the new vector set data type, well, queries are threaded by default, and you can even use VADD (so writing to a vector set) in a threaded way. Why I changed my mind? Because HNSWs are the first data structures with huge constant times, Redis never had something like that, and this changed the design space that was worth considering. So in 2020 I was already positive about threads, in the past I already had implemented the threaded support for moduels operation, and now vector sets are threaded. It is not about being pro or against, it depends.

christophilus 1y ago

detail_orient 1y ago

I had heard about Valkey last year and am glad is going strong!

secondcoming 1y ago

Does Valkey provide their own client library? We use Redis all over on GCP both via MemoryStore and on custom machines. We use both classic Redis and Redis Cluster. The official C library is sadly quite deficient if you want to use Redis Cluster and then TLS. We have to use an unofficial hiredis-cluster client [0]. It's a real pain for us. We're considering moving to Scylla. GCP's Memorystore is a joke too. [0] https://github.com/Nordix/hiredis-cluster https://github.com/Nordix/hiredis-cluster

michael_grunder 1y ago
Yes, there is a combined fork of hiredis and hiredis-cluster called libvalkey. It is maintained by many of the same people who have maintained hiredis and hiredis-cluster. https://github.com/valkey-io/libvalkey https://github.com/valkey-io/libvalkey