Kind of, but it’s from my FreeBSD days. It was early 2000s, and at that point I’d been using it since version 3.3, and I was toying with 4.4, and I was getting into kernel optimization. I started removing the things I didn’t need.
A lot of it was simple, such as firewire support, etc. Then I came to the section about peripherals. “AT keyboard? Yup, that’s going”
Welp, turns out PS/2 keyboards were built on top of the AT keyboard subsystem. Luckily I could SSH into it and revert the change.
You’re going to get a million answers, mostly people saying to use which distro they’re currently using. In my experience, KDE works just fine on any distro that allows you to install it out of the box, so I would choose based on other attributes of the distro, such as:
Package manager: which are you used to?
Update cycle: KDE 6 is out soon, so you want something which updates often enough to get it fairly quickly (at least semiannual).
Stability: unless you want to have to manually maintain your system and learn how it works, avoid arch and arch-based distros. I have run it, its fine, but it’s not “normie”, and unless you really know what you’re doing, daily driving it can be stressful. Manjaro has the same issues, but takes away some ability of the user to fix them.
For instance, I personally like Debian and apt, but I would not recommend base Debian right now, since KDE 6 is about to come out and Debian will take a loooong time to get it. I have not personally used Kubuntu, but if it gets rid of any the bloat canonical has been adding to Ubuntu lately, it sounds pretty good to me.
Yeah, Kubuntu’s fine. It has some of the Snap stuff, but the “minimal install” greatly strips down unnecessary bullshit to the point where I even find vanilla Debian Plasma to be more bloated in comparison.
I used Kubuntu for most of my time on Linux before switching to Debian. Still fully recommend it as a basically “plug and play” distro with a quick installer that works OOTB.
There’s also a KDE-specific backports PPA which gets you new Plasma and Qt stuff fairly quickly, but that works best on regular releases rather than LTS releases. (The only issue is that, because it uses Launchpad, the Plasma updates can be super fucking slow to download, regardless of your network speed).
Then again, if someone’s going to be using LTS versions only, there’s not really that much of a difference between it and Debian Stable in terms of DE updates.
I tried some distros but always went back to Ubuntu and then I settled there. Until like 3 days ago. I installed Parch (basically Arch with a GUI installer) and I think I will stay for the AUR.
user@hostname:$ ls /etc/subuid ls: cannot access ‘/etc/subuid’: No such file or directory user@hostname:$ ls /etc/subgid ls: cannot access ‘/etc/subgid’: No such file or directory
Well, that’s your problem. sub?id is what defines which uids and gids are available to a user for purposes of making user namespaces. It’s strange that those files don’t already exist; useradd should create them automatically. What distro are you using?
Regardless, you can create those files yourself. Here’s a line from subuid my machine: administrator:100000:65536. The first field is the username (you can also use a uid), the second is the starting uid for the block of uids, and the third field is the number of uids in that block. So uids from 100000-165535 (inclusive) are allocated to the user administrator.
I used to spend an unhealthy amount of hours customizing my desktop (Plasma) just to distrohop and repeat that cycle one million times. Then I just got used to the vanilla state of Plasma, and now I really don’t care about that at all.
For people that still care and distrohop, there’s a tool called “konsave” which allows you to save, restore and export specific Plasma customizations (settings included). You only have to reinstall themes you had to install as a package/compiled it.
You skipped a step or two in your podman setup I think. Look up the rootless instructions, and make absolutely sure you have installed the right uid/gid packages for your distro.
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.
That’s the beauty of Linux! If you feel adventurous, you always easily find something to tweak/experiment. Since I moved to Linux my mindset and workflow never ceased to evolve. That’s because I’m curious but that couldn’t be possible in any other OS. Only Linux can offer so much options and an exceptional level of granularity so anyone can build his/herown perfect system. We may achieve the same thing but in different ways and we’ll both run Linux.
If you’re more shy you can simply install a set of software under a given distro and you’re done. This is also a Linux option. Right now, I couldn’t find any challenges to keep me busy for more than a day or two until I decided to test a new system (NixOS) in a virtual machine. This is another way to have the kind of fun you mention :)
I love tweaking and improving my system so much that I dedicated my little blog only to that. Sharing is another crucial principles I love in the Linux philosophy.
I tried Arch in a VM about when Archinstall came out. And after the first install, I did it again with archinstall | lolcat. The configuration part was a little buggy, but let me tell you; it was worth it.
Thanks, yeah I’ve found a few articles already on running scripts at shutdown…something like this should do it (using Tony Walker’s update script), though I’ve not tested it yet:
Drivers is a vocabulary you should almost forgot in Linux ;) Contrary to other OS, Linux will rarely require you to install a driver.
To answer your question, doing a simple online “mint wireless 8275” returned a forum with your exact issue. The reported solution is to “try powering it off, remove the power cord and hold the power button for 30 seconds. Reconnect cord and power up”. As weird as it sounds this may work. It worked for me 10 years ago with a keyboard. It’s easy and quick to try it. Let us know if that helps or not. Too bad you didn’t like Arch because your laptop was fully supported.
Unless you are suggesting they find a way to remove the battery, “removing the power cord and turning it on without actually turning it on” isn’t something they can try.
And the fact that WiFi works on another distro suggests this isn’t a weird bug-state that the card needs to be snapped out of with power-cycling tricks.
OP has solved his issue already but the trick I mentioned could be due to a capacitor issue which can occur anytime and break things that worked before.
I was just trying to help by suggesting an approach that solved the exact same issue on others’ laptop running the same distro. Even though not convenient you can either wait for your battery to run out or disconnect it to try this trick.
That trick screams “residual power in a capacitor that we need to drain to get a proper restart on some component”
I’ve heard of that working with some motherboards where it seemed they were dead and may explain those boards that don’t work but magically do months later when the capacitors had time to completely discard the small trickle of current they still had.
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.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.