Hardware related stuff like this typically comes down to the kernel version, or what kernel modules the distro ships. The linux kernel comes with a ton a drivers for different hardware, each of which implement support for hundreds/thousands of pieces of hardware. The wi-fi driver shipped with Mint isn’t new enough to include an implementation for your specific wi-fi hardware.
Mint seems to be on an LTS 5.X kernel, while Pop is shipping newer 6.X kernels (makes sense, as they like to keep up with gaming-related improvements).
As an example, I had to jump to a newer version on Manjaro, when the LTS kernel used by default was just one digit behind the version that was new enough to have support for the PS DualSense5 controller.
Hopping to a newer kernel version can be tricky depending on the distro, but it looks like Mint has a tool for this. You can find it in the Update Manager: View --> Linux Kernels. There you should be able to switch to running a 6.X kernel version.
I use uBlue and update manually (using a custom alias/script) whenever I get the time, like say during my lunch break or something. Reason being, I actually like watching the update process and seeing what gets updated, watching out for major version number changes or major package upgrades, and if I’m interested I may look up some of their changelogs to find out about their new features etc.
and being forced to reboot
You should be forced to reboot though? And if you don’t want to reboot, can’t you just do an –apply-live? I mean you’d still need to reboot for a kernel update but for the most part, you should be able to use most of your new packages without a reboot. And this holds true even more so if you’re updating Flatpak/container/Nix/pip/cargo/brew packages. And I hope you’re not doing the rookie mistake of actually installing stuff at the ostree layer instead of using Flatpaks/containers/Nix etc.
I too like to review changes between images, but I’m just as content to run rpm-ostree status and/or rpm-ostree db diff to see what exactly has changed.
You should be forced to reboot though? And if you don’t want to reboot, can’t you just do an --apply-live?
I’m hoping to eliminate the extra reboot each day that is usually necessary to activate the latest image. I know that a lot of this will depend on exactly when the image drops from the repos (versus when I shutdown a host), which is why I was looking for some general feedback from others who might have done the same thing…I didn’t know if it’d be worthwhile in the long run, but I guess there’s only one way to find out. As for the –apply-live, I use it on occasion but I don’t want to rely on it for system updates (if that’s even possible).
As for the –apply-live, I use it on occasion but I don’t want to rely on it for system updates (if that’s even possible).
As I said before, it does work for system updates, the only exception being the kernel. The –apply-live flag was added for that exact reason, to avoid the need for an unnecessary reboot.
Check out OpenRGB to see if it meets your lighting needs. I use it with Corsair Commander Pro, keyboard, mousepad, RAM, QL fans and the ASUS RGB header and attached lighting. It’s been working great on OpenSUSE Tumbleweed for me.
Some great newer tech distros would be Fedora Silverblue, or if you like Debian, there is VanillaOS. They are immutable distros, and they introduce a new way of using Linux. I like to pair it with distrobox, which lets you use regular Linux applications in a container.
linux
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.