A new component “systemd-bsod” has been added to show logged error messages full-screen if they have a “LOG_EMERG” log level. This is intended as a tool for displaying emergency log messages full-screen on boot failures. Yes, BSOD in this case short for “Blue Screen of Death”. This was worked on as part of Outreachy 2023. The systemd-bsod will also display a QR code for getting more information on the error causing the boot failure.
Hibernation into swap files backed by Btrfs are now supported.
Actually looking forward to the btrfs swapfile hibernation; I have tried setting it up on my machine before but the documentation was never clear on whether it would work (or why mine wasn’t).
So I don’t get it, I have my entire boot image in a signed EFI binary, the logo is in there as well. I don’t think I’m susceptible to this, right? I don’t think systemd-boot or the kernel reads an unsigned logo file anywhere. (Using secure boot)
Depending on how the UEFI is configured, a simple copy/paste command, executed either by the malicious image or with physical access, is in many cases all that’s required to place the malicious image into what’s known as the ESP, short for EFI System Partition, a region of the hard drive that stores boot loaders, kernel images, and any device drivers, system utilities, or other data files needed before the main OS loads.
Right, I know EFI images are stored in the EFI partition, but with secure boot, only signed images can be executed, so they’d need to steal someone’s signing key to do this.
If looking to put in the work while also leveling up in programming since you have some basic experience already, NixOS/Guix should be on your shortlist.
Both have programmatic, declarative configuration instead of a mangle of configuration files that tend to break with entropy as software developers update config files & it’s very easy to miss a broken build until you restart (I remember when PAM had an update & a lot of folks, including myself, panicked as they could no longer log into their machines). Since these config files are tied to versions of software, such issues are much rarer, & with stateless config you get rollbacks to previous working versions for free. Both ship with a powerful package manager that can replace bad programming language package management & tools with overhead like Docker.
The biggest downside is having to learn Nix (language) or Guile Scheme to be able to script your config, but once you get the hang of it, it’s hard to feel confident in any stateful system & you learned valuable skills for package management.
That's a good point, I could jus try debian and remove the unnecessary stuff. I want my daughter to use this laptop so it needs some video codecs and hopefully some educational games.
Some commenters said you need a minimum of 2GB memory to run Debian. What do you make of that?
I wouldn’t use CentOS for private/ desktop stuff personally.
Do you really need its features? Afaik, the “security” features you mentioned are mainly for server use. At least that’s what I have in my mind right now when I researched possible candidates for my home server some time ago.
I think sticking with a “home use” distro would suit you better.
There are a few options as suggestions:
Stay on Kinoite
==================
There’s barely any configuration drift compared to the mutable Fedora. Therefore, it should be less buggy.
Fedora Atomic KDE gave me the best Plasma experience yet. I often tested KDE (I’m a Gnome guy myself, but here and there hop to KDE for a few months) and on most installs on other distros like Suse/ Workstation/ Debian, it got more and more buggy after a few weeks due to updates and tweaks.
So, bugfixes often didn’t apply to my system, only the default one or the install from the devs.
I find Fedora’s release schedule to be the perfect sweetspot between reliable, stable and up to date.
If you’re really impatient, you can always switch to the nightly builds (on Atomic), which are more bug prone and rolling. Maybe, Plasma will be stable enough before it hits the official image. But you should keep at least one stable image in your bootloader.
Debian and Leap
==================
Debian “just” got it’s new release and will be stale for the next years. BUT, many of those Plasma 6 bug fixes will be backported to 5.27. Still, many of the QOL-changes are 6-exclusive.
OpenSuse Leap also gives you a great KDE experience and is pretty similar to Debian, both in release schedule and when the last big update hit.
Distrobox
============
You can use an Arch/ Tumbleweed container on Debian/ slow release distro to get all the newest KDE stuff on the outside and keep your stable base beneath.
Why? Because, in my experience, Plasma only gets more refined each update. As long as there aren’t any new big features, there are about hundred bugs resolved weekly.
Or, you can do the opposite. Use something newer, like TW, Slowroll, Sid(uction) or Arch, to get the newest software under the hood, and use the Debian repo to get a stable DE.
Just what you prefer.
In your case, I’d settle with Fedora (mutable or Atomic, in your case the Kinoite version, as I’d prefer that one too), and just don’t upgrade to the newest version.
The older version is always supported for a year or two, and you don’t have to upgrade each release. The bug fixes always get backported if possible.
Thanks! Yes its a shame that Debian (and Leap?) Will not have Plasma6 in like 6 months where stable release would fit perfectly.
My experience is the same, on Manjaro Plasma was way better than on Kubuntu and Manjaro convinced me of Plasma. Fedora is a sweet spot and staying with F39 for a while (even though I will probably switch to F40 right away as Plasma6 has sooo many bug fixes I personally reported) could work.
You mean a rootful Distrobox with a DE in it? I have to try that out, sounds crazy. Would need a seperate home if that is possible, as I dont want to have messed up dotfiles.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.