Redis, a popular in-memory data store, is being deprecated in Arch Linux's repo; Valkey steps in as a high-performance BSD-licensed replacement.
https://linuxiac.com/arch-says-goodbye-to-redis-adopts-valkey/

#arch #redis #valkey #nosql #database #OpenSource

Arch Linux 打算淘汰掉 Redis，改用 Valkey

在 Lobsters 上看到 Arch Linux 要用 Valkey 淘汰掉 Redis 的消息：「Valkey to replace Redis in the [extra] Repository」。 Redis 會從官方的 repository 搬到 AUR 上，然後就隨緣： Arch Linux Package Maintainers intend to support the availability of the redis package for roughly 14 days from the day of this post, to enable a smooth transition to valkey. After the 14 day transiti…

https://blog.gslin.org/archives/2025/04/18/12355/arch-linux-%e6%89%93%e7%ae%97%e6%b7%98%e6%b1%b0%e6%8e%89-redis%ef%bc%8c%e6%94%b9%e7%94%a8-valkey/

#arch #archlinux #license #linux #open #redis #source #valkey

🛠️ Title: VSCodium
🦊️ What's: A libre IDE
🏡️ https://vscodium.com
🐣️https://github.com/VSCodium
🔖 #LinuxGameDev #Flagship #Programming #IDE #Telemetry
📦️ #Libre #Bin #Arch #RPM #Deb #Flatpak #AppIm #Snap
📖Our entry: https://lebottinlinux.vps.a-lec.org/LO.html

👹️ Telemetry: https://github.com/VSCodium/vscodium/issues/1322

🥁️Update: 1.99.02289 (=vsc 1.99.0)➜1.99.32562 (=vsc 1.99.3)
⚗️Major release (Stable) 🍎️
📌️Changes: https://github.com/VSCodium/vscodium/releases
🦣️From: 🛜️ https://github.com/VSCodium/vscodium/releases.atom

🦝️https://www.youtube.com/embed/P8accXNcwjs?start=633
🕯️https://www.youtube.com/embed/?list=PLjCGSCBfSFa9jbjQuGCtJ3Ncl3Xyr8Mn_
🐧https://www.youtube.com/embed/jtK-prBAyPo

#HDF5 jest super. W skrócie:

1. Oryginalnie, projekt używał systemu budowania autotools. Instalował binarkę h5cc, która — obok bycia nakładką na kompilator — miała dodatkowe opcje do uzyskiwania informacji o instalacji HDF5.
2. Później dodano alternatywny system budowania #CMake. W ramach tego systemu budowania instalowana jest uproszczona binarka h5cc, bez tych dodatkowych funkcji.
3. Każdy, kto próbował budować przez CMake, szybko odkrywał, że ta nowa binarka psuje większość paczek używających HDF5, więc wracano do autotools i zgłoszono problem do HDF5.
4. Autorzy zamknęli zgłoszenie, stwierdzając (tłum. moje): "Zmiany w h5cc przy użyciu CMake zostały udokumentowane w Release.txt, kiedy ich dokonano - kopia archiwalna powinna być dostępna w plikach z historią."
5. Autorzy ogłosili zamiar usunięcia wsparcia autotools.

Co stawia nas w następującej sytuacji:

1. Praktycznie wszyscy (przynajmniej #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) używa autotools, bo budowanie przy pomocy CMake psuje zbyt wiele.
2. Oryginalnie uznano to za problem w HDF5, więc nie zgłaszano problemu innym paczkom. Podejrzewam, że wiele dystrybucji nawet nie wie, że HDF5 odrzuciło zgłoszenie.
3. Paczki nadal są "zepsute", i zgaduję, że ich autorzy nawet nie wiedzą o problemie, bo — cóż, jak wspominałem — praktycznie wszystkie dystrybucje nadal używają autotools, a przy testowaniu budowania CMake nikt nie zgłaszał problemów do innych paczek.
4. Nawet nie mam pewności, czy ten problem da się "dobrze" naprawić. Nie znam tej paczki, ale wygląda to, jakby funkcjonalność usunięto bez alternatywy, i tym samym ludzie mogą co najwyżej samemu zacząć używać CMake (wzdych) — tym samym oczywiście psując swoje paczki na wszystkich dystrybucjach, które budują HDF5 przez autotools, o ile nie dodadzą dodatkowo kodu dla wsparcia tego drugiego wariantu.
5. Wszystko wskazuje na to, że HDF5 jest biblioteką, której autorów nie obchodzą ich własni użytkownicy.

https://github.com/HDFGroup/hdf5/issues/1814

#HDF5 is doing great. So basically:

1. Originally, upstream used autotools. The build system installed a h5cc wrapper which — besides being a compiler wrapper — had a few config-tool style options.
2. Then, upstream added #CMake build system as an alternative. It installed a different h5cc wrapper that did not have the config-tool style options anymore.
3. Downstreams that tried CMake quickly discovered that the new wrapper broke a lot of packages, so they reverted to autotools and reported a bug.
4. Upstream closed the bug, handwaving it as "CMake h5cc changes have been noted in the Release.txt at the time of change - archived copy should exist in the history files."
5. Upstream announced the plans to remove autotools support.

So, to summarize the current situation:

1. Pretty much everyone (at least #Arch, #Conda-forge, #Debian, #Fedora, #Gentoo) is building using autotools, because CMake builds cause too much breakage.
2. Downstreams originally judged this to be a HDF5 issue, so they didn't report bugs to affected packages. Not sure if they're even aware that HDF5 upstream rejected the report.
3. All packages remain "broken", and I'm guessing their authors may not even be aware of the problem, because, well, as I pointed out, everyone is still using autotools, and nobody reported the issues during initial CMake testing.
4. I'm not even sure if there is a good "fix" here. I honestly don't know the package, but it really sounds like the config-tool was removed with no replacement, so the only way forward might be for people to switch over to CMake (sigh) — which would of course break the packages almost everywhere, unless people also add fallbacks for compatibility with autotools builds.
5. The upstream's attitude suggests that HDF5 is pretty much a project unto itself, and doesn't care about its actual users.

https://github.com/HDFGroup/hdf5/issues/1814