previously @[email protected], @[email protected]
Lemmy.zip
Linux @lemmy.ml Distro Recommendation Discussion (Not a 'What Distro Should I Use?' Post)
Realistically, any LTS distro from a netinstaller or minimal image that can use a kiosk compositor like cage. So, the usual suspects of Debian, OpenSUSE, AlmaLinux, RockyLinux (or a derivative of one if the native distro doesn't support Raspberry Pi). Then you just have cage open the browser of choice on startup (e.g.
chromium --kiosk <url>) and you have a lightweight and relatively secure web kiosk.More or less yes, minus the copying files back if the operation was successful. You must be careful shrinking partitions as it is very easy to destroy them, and I'd have to guess the partition layout looks vaguely (EFI System Partition (
/boot/efi), Boot (/boot), Root (/), ...), which would require shrink and move of the partition before or after/boot. If you're unfamiliar with shrinking a partition, a bit of reading into how it is done for your filesystem will be required. Different setups, ext4, btrfs, lvm, LUKS, etc. will have different requirements.Checking the /boot size on my Fedora install, I partitioned out a gibibyte for the 3 kernel plus recovery kernel setup, which takes up about 338 MiB in total. Depending on out-of-tree kernel modules and bootloader modifications installed, your initramfs images could be larger. A few things to look for:
- the size of your current initramfs and vmlinuz image(s)
- any kernel modules you needed to install alongside your system (v4l2-loopback, nvidia, realtek, etc.)
- If there are other large files present in the boot partition
If everything there looks fine and/or is necessary, you might need to expand your /boot partition (either reinstall if new system or offline partition shrinking, moving after a data backup if you have personal files you care about).
You're likely looking for this docs section for Caddy. The failure is the automated request to populate Caddy's root CA cert to the host system, but obviously failed as it doesn't have root permissions. As the docs state, if you intend to use the local HTTPS functionality of Caddy, you can manually run
caddy trustprivileged in order to populate the Caddy root CA cert manually. If you intend to disable the local HTTPS functionality (such as if you're running Caddy behind a http reverse proxy), you can ignore the mail message.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.
If you happen to remember, what DE's/WM's did you use back when testing with your NVidia cards (particularly the 2080 and 3070)? I've been trying to gauge a lot of differences in DE usability, and driver versions. In my recent testing, one user on Fedora KDE 42 with the NVidia-open drivers with a 4070 have had a nearly-flawless experience that would be pretty much on par with AMD or Intel. Meanwhile a 1080ti user genuinely had major problems with both KDE and GNOME on the same distro with the standard proprietary drivers.
As for how much the average user needs to use the terminal on modern distros, especially with some of the graphical tools available, it genuinely is very little, if any at all. I think there is more of a problem with how many guides written go for the least common denominator approach of straight terminal commands for every tweak or fix somebody might look up. It is to a point where I might start attempting to write a series of guides and/or short-form videos for a lot of the more common 'how-to' and frequent problems that many users might encounter, both for GNOME and KDE at least.