Eventually tagging cache will have to come back to #Laravel sooner or later.
What about trying to re-implement it in time for Laravel 13? That would mean to depend on Symfony Cache.
https://symfony.com/doc/current/cache.html#cache-using-cache-tags

Eventually tagging cache will have to come back to #Laravel sooner or later.
What about trying to re-implement it in time for Laravel 13? That would mean to depend on Symfony Cache.
https://symfony.com/doc/current/cache.html#cache-using-cache-tags
Bon, apparemment #keydb à décidé de planter tout le serveur. Pratique, simple . Ca va que j'ai accès à la prise.
So after all this time, what is the established Redis alternative? Is is valkey? Keydb? Or something else?
@anderseknert
how would we compare and contrast #valkey, #keydb, #dragonflyDB
also the legal framework and future exposure to #enshitification
I work on linux and open source solutions only.
This discussion on HN about why you may not need anything other than Postgres: https://news.ycombinator.com/item?id=42036303
brings up a good question about Redis- one I've wondered myself: Are we using Redis the wrong way?
The main use of Redis is as a simple key/value store. The idea is that if we are doing a process such as a DB query, we can cache the result. This is essentially memoization, and I remember this being used way back with a program called memcached.
Redis is a highly optimized key/value store, but many people (myself included) use hosted Redis servers. This introduces a lot of overhead on reads.
Wouldn't we be better off moving the key/value pair server as close to the application as possible, and then relying on writes being distributes to all instances? At worst we might get old data, but if we're using the system for caching, that shouldn't matter much, and we can instead rely on eventual consistency.
I'm curious as to other's thoughts on this.
Expanded the Always Open project with the details of #OpenTofu #OpenSearch #Valkey #Redict and #KeyDB. I was surprised that KeyDB doesn't appear to use the DCO or other formal contributor agreement.
The Redis "in-memory data store" project to a non-free license https://www.admin-magazine.com/News/Redis-Switches-to-Non-Free-License #Redis #KeyDB #Valkey #FOSS #OpenSource #FreeSoftware #license
And now @realkeydb builds are in Bodhi for all supported @fedora versions and EPEL 8/9 and ready for testing.
Good alternative and potential replacement to #redis
https://bodhi.fedoraproject.org/updates/?search=keydb-6.3.4-2
3 serious forks of #Redis to watch:
Mutli-threaded fork of Redis based on Redis 6.
BSD 3 Clause license.
Owned by Snapchat.
https://github.com/Snapchat/KeyDB
Recent fork by @drewdevault@fosstodon.org based on the last open source version of Redis 7.2.4.
On Codeberg.
LGPL 3.0 license.
https://codeberg.org/redict/redict
Accepted by Linux Foundation. Started by former Redis contributors & AWS employees.
BSD 3 Clause license.
https://valkey.io/
Boosts appreciated
@Elucidating Again:
Check my #GitHub contributions and see for yourself...
The #rugpull by #Redis is just inexcuseable and not only did #Snapchat basically make a better #multithreaded #fork under #BSD 3-Clause named #KeyDB for quite some time , but several big constributors seem pissed...
So far, I saw quite significant contributions from #Tencent *, #AlibabaCloud * #aws and #RedHat and I'm convinced their #CLO's are pissed since their staff worked on those projects because with the leave of original creator of Redis it was stated that it will remain 3-Clause BSD...
And I do expect Redis to get their asses handed in court so hard they'll have to file for #bankrupcy like #SCO before the dust has settled...
I mean, look at that dumpsterfire and tell me with a straight face this is how #FLOSS should be done!
If you're using #redis 6 on #EPEL and want to try out #KeyDB, here's a quick way to switch:
sudo dnf copr enable jonathanspw/keydb && sudo dnf swap redis keydb && sudo systemctl enable --now keydb
Keep in mind that you may need to port over any custom redis config to /etc/keydb and persistent data to /var/lib/keydb.
Thanks @jonathanspw for getting this going!
Do you know a thing or two about #redis internals? #KeyDB from #SnapChat is looking for contributors to help them rebase to the last BSD release of redis 7. If you want a multi-threaded #opensource drop-in replacement to be a reality for redis v7 users, please report for duty over on their git repo: