Are you on systemd or openrc? I can't say I'm a fan of systemd, but I'm not religious about it.
Both - I set up the old Raven Ridge based convertible laptop using systemd explicitly so that I could use iio-sensor-proxy to handle the accelerometer without having to try to liberate it from systemd myself (I subsequently found an overlay where someone had done exactly that, but too late).
It still seems to me to be a solution in search of a problem. Boot speed is no faster, and yes, enabling Plasma’s system monitor to display per process statistics in a similar format to Windows task manager is cute but “top” exists and does the same thing. Systemd service files are slightly easier to write than openrc scripts, but that’s something you’ll deal with maybe once in a system’s lifetime. Binary logging is a pain and you’ll still pipe logging output to syslog-ng. Systemd’s boot loader is functional but grub is still more flexible. Systemd’s network handler works but you’ll still use NetworkManager.
Even on openrc, though, you still end up with systemd components as dbus, udev, session handling and a few other components of desktop environments have been folded up into the cube…
…as ambivalent as I am on the subject, resistance is ultimately futile.
I've got Gentoo servers, and I absolutely love the freedom they give me because I can get the build tuned to what I want. It's remarkably hard to get Redhat to operate in a minimalist environment.
Desktop Gentoo is a nice experience, especially for a KDE Plasma user… I’ve always wanted Windows/Mac functionality without the cost, and a DE that gets out of my way and lets me work. Most of the packagers seem dead set on pushing Gnome and its derivatives, which I’ve always felt is the Tomy toy expression of a DE.
Given its focus on corporate customers, and the security drives of most companies, you'd think it would be easier to minimize the attack surface in e.g. Redhat by not having to install a bunch of dependencies that don't have anything to do with what you're actually building the server for, but it's not. It's incredibly easy to prevent installing of a package that you know you don't use (e.g. Mandarin character sets) and suddenly discover that some other package you have installed has a built-in dependency on that package. While we can argue that the real issue there is a poorly packaged application (and it is), the fact remains.
Because they’re selling worldwide, if they didn’t include the dependency on e.g. a random character set (presumably for a program that doesn’t properly support UTF) they’ll get a tickets from Far Eastern users complaining that they only see boxes. The need to be all things to all men does make the packaged distros a balance of compromises.
They (and giving credit, MS and Apple) do balance it pretty well… I’m just a cantankerous old git and want my suit made to measure.
Instead, most CorpSec seems to be focused on installing still more packages to bring in IDS, AV, and ACL to solve problems that shouldn't even be there if you didn't have to load a whole bunch of cruft that you don't actually need.
I recently supported our external information security audit - it is very much a box checking exercise. The external auditor is trained in the standards, but is not a cybersecurity expert.
It is simply easier to point to a product and say, “this fulfils that criterion” rather than to try to explain actual risk profiling and risk reduction measures. The former gets you a gold star, the latter a bunch of “observations” or “opportunities for improvement.” Or a non-conformity based on the assessor’s lack of understanding.
Thankfully my role isn’t IT focused - I only needed to prove that we don’t let any old numbskull on the project read commercially sensitive info… and there’s a product for that
