jrgd

Certainly glad I had my suspicions of Bitnami rugpulling when constructing my Kubernetes cluster and preemptively stripped out as much as possible from helm charts that relied on anything Bitnami. This is going to suck for a lot of people and organizations given that images like rabbitmq, postgres, oauth2-proxy, minio among many others are affected.

It’s not a full rugpull yet, but not being able to pin versions for the newer security-hardened images is already a huge issue for many pieces of software. Especially for things like not being able to pin to a major version of postgres will cause major problems over time for cluster admins and helm chart developers alike if they don’t migrate to other solutions.

Who knows if (when) Bitnami decides to go further in restricting their images, charts from being free and open. I do wish in the future that more helm chart developers would know the caution that should be taken when trusting anything touched by Broadcom of all companies. Maybe this is the necessary warning sign for many.

The Nullobsi fork of Cantata or many other mpd-backed music players are something I can recommend seems to fit what you’re looking for. It supports being able to edit the play queue whilst running a single-track on repeat within it. It does also support fade out and crossfade. The easiest way to obtain it is via its flatpak on Flathub. Cantata can either run an integrated or connect to a system-level mpd server for its backend.

Some modern laptops have completely removed support for S3 sleep, as well as some still include it but clearly never tested it. I have seen multiple OEMs that have S3 sleep “available” but with the Windows installation utilizing S0 by default. If such OEMs are lazy (which a lot of them are), they just won’t bother to properly test the functionality as long as the default OS configuration they ship works. Same kind of deal now with how many OEMs (mostly used to) ship non-standard ACPI implementations that required extra drivers in Windows to function (or would just not work correctly under Linux).

Based on the information given in logs + the rest of the thread thus far, I’d assume the problem either lies in a kernel bug or the laptops’ firmware, BIOS. The logs claim the system successfully going into S3 (deep) sleep. It’s possible for the affected laptops to have broken S3 suspend behavior.

A few things that might be worth checking include seeing if other sleep modes (s2idle) are available and testing them, checking for BIOS updates, and checking for Linux/generic suspend options within the BIOS.