Nobara KDE user here. One of the reasons why I chose it is because it comes with many of the customisations that I’d normally do (such as using an optimized kernel). But in addition, I use:
Opal instead of LUKS
KDE configured with a more GNOME/macOS like layout (top panel+side dock)
GDM instead of SDDM, for fingerprint login
Fingerprint authentication for sudo
TLP instead of power-profiles-daemon for better power saving (AMD P-State EPP control, charging thresholds etc)
No such issues here with my XM5, been using mine for over an year. Are your devices on at least Bluetooth v5.2? All of mine are either 5.2 or 5.3 and I’ve not experienced any issues. I use my headphones with Android, Linux, Windows 10 and macOS. Even multipoint works fine.
As for the head comfort, you could get a headband cover/cushion, such as the ones made by Geekria.
As others have mentioned, the sequential speeds in RAID 0/5 won’t really help you in gaming. What you might see at best is faster loading times, but that’s really about it.
One option which no one else has mentioned is using setting up tiered storage using bcachefs - where your SSD acts like a cache drive, which would contain frequently read aka “hot” data, and the rest of the data would be on your spinning disks. This way, you’d be making the most of your limited SSD space, whilst still taking advantage of the large storage provided by the spinning disks.
The advantage of bcachefs is that all your drives can be part of the same pool and it’ll all be transparent to your OS/programs, and all your data is striped like a RAID 10 array, so you can replace your drives in the future without any issues, or any major config changes. Like if you get a faster NVMe drive in the future, you can set that as your “hot” (promote) drive, your SSD as the foreground drive and your spinning disk pool as the background ones and your data will automagically migrate.
The main drawback right now (for you) is that it’s not yet part of the kernel. The good news is that it’s gonna be in the next kernel (6.7), so you can either wait for it, or use a third-party kernel with bcachefs already compiled in it (I believe linux-tkg is one of them).
Foreground targets are where writes initially go. Data is moved from foreground to background targets while idle or as needed. Data which is read from the background targets is moved to promote targets.
If you set your NVMe as a promote target, SSD as foreground and your HDDs as background targets, all writes would first go to your SSD, then get copied to your HDD during idle, and finally the copy of the data on your SSD will then be marked as a cached copy. In case your SSD becomes full, then it’ll store the data on other drives. As for the promote targets, any time you read data from either the SSD or HDD that wasn’t on the NVMe, it would get cached to it, so the next read will be faster.
The main point of the foreground vs promote is to prioritize write vs read speeds. If you value faster writes, then set your NVMe as foreground. If you value faster reads, then set your NVMe as promote. Of course, you can also set your NVMe as both foreground and promote to benefit from both faster reads and writes.
But since you plan to introduce an SSD in the mix, you can create a single group for your NVMe + SSD, and a second group for the HDDs, and set your SSD group to foreground + promote, which will simplify things.
If you’re concerned about chucking both the SSD and NVMe in the same group, no need to worry cause bcachefs will automatically prioritize reads from drives with lower latency as mentioned in the wiki.
If they are different speeds, reads for replicated data will be sent to the ones with the lowest IO latency.
But regardless of which setup you go for, main thing to remember is to use the NVMe (or the group containing the NVMe) as the promote target, as that will be your primary cache drive.
As KDE F38 user, this is a super boring release. Nothing noteworthy for us to look forward to except LibreOffice 7.6 - which you can get via Flatpak anyways. I was hoping the new DNF 5 would make the cut, but guess it’s still not ready yet. :(
Guess will have to hold out my excitement until F40 for Plasma 6 and DNF 5 (hopefully).
Meh. As a KDE F38 user, this is a super boring release. Nothing really new for us to look forward to, except LibreOffice 7.6 (which you can get via Flatpak). I was hoping the new DNF 5 would make the cut, but guess it’s still not ready yet. :(
Guess will have to hold out my excitement until F40 for Plasma 6 and DNF 5 (hopefully).
Just use a terminal multiplexer to split your screen (so you don’t need a separate tab), and then ceate an alias/session file with your monitoring programs so you can call it with a single command.
Yes, I do provide a password on boot, as you said, keys can be extracted from the hardware so that’s not secure, which is why I don’t use the TPM to store the keys.
There are no hooks necessary in the bootloader, as it’s the BIOS which prompts you for the password and unlocks the drive.
And yes, there have been implementation problems in the past, but that’s why the Opal 2.0 standard exists - don’t just buy any random self-encrypting drive, do your research on past vulnerabilities for that manufacturer, and check if there are any firmware updates for the drive (don’t just rely on LVFS).
Also, the common hardware attacks rely on either a SATA interface (to unplug the drive while it still has power) or older external ports vulnerable to DMA attacks such as PCMCIA or Thunderbolt 3.x or below; so those attacks only affects older laptops. Of course, someone could theoretically install a hardware keylogger or something, but this is also why you have chassis intrusion detection, and why you should secure and check any external ports and peripherals connected to your machine. Overall physical security is just as important these days.
But ultimately, as always, it comes down to your personal threat model and inconvenience tolerance levels. In my case, I think the measures I’ve taken are reasonably secure, but mostly, I’ve chosen Opal for performance and convenience reasons.
Opal drives are self-encrypting, so they’re done by the disk’s own controller transparently. The main advantage is that there’s almost no performance overhead because the encryption is fully hardware backed. The second advantage is that the encryption is transparent to the OS - so you could have a multi-boot OS setup (Windows and FreeBSD etc) all on the same encrypted drive, so there’s no need to bother with Bitlocker, Veracrypt etc to secure your other OSes. This also means you no longer have a the bootloader limitation of not being able to boot from an encrypted boot partition, like in the case of certain filesystems. And because your entire disk is encrypted (including the ESP), it’s more secure.
I thought NixOS was already reproducible, like, isn’t that the whole point? What’s the big deal here, and why is it a “great achievement” - does the Linux world now completely change? Does this revolutionize how Linux ISOs are built?
At least KDE is planning to introduce customisable trackpad gestures next year, with Plasma 6.0. Not sure if that would include palm rejection though or the other stuff.
I used it at work recently to update my work-provided HP Thunderbolt dock, and it resolved an issue where the external monitors would fail to activate after resuming from standby. I never got an update notification when I was using my Windows laptop so I was oblivious to it; it was only thanks to connecting it to my Linux laptop and fwupd, that I found out there was an update, which subsequently resolved the issue.
I love it when stuff like this happens and Linux saves the day. =) (and I get to show off to my Windows heathens colleagues.)
Yeah, unfortunately it looks like the reader on the X1 is a special case. Thankfully, this isn’t an issue with my Z13 - the reader itself worked out-of-the-box, just had to enroll my fingerprint from the Settings menu and then added fprintd to my pam.d rules.