> Really, it's only on you to fix it if it does not work, which in my experience is far less likely with systemd.
That's just lazy if your waiting for systemd to report you a failure. It's on you to maintain, ensure it's all operating correctly; including the daemon starting and stopping manually correctly.
Makes sense that on machines I've inherited that such checks are not done.
I've been running Arch continuously without a single complete reinstall for a decade now. I don't think it's fair to claim I wouldn't know how to maintain my systems correctly.
I'm not advertently claiming you cannot. But working with teams and systems where they wear the badge of "I'm a DevOp who can SysAdmin" and try to prove themselves in such as a manner throws myself a sigh.
If your unable to compile your own kernel, you don't pass in my books, it's a rite of passage.
> If your unable to compile your own kernel, you don't pass in my books, it's a rite of passage.
Pulling the PKGBUILD (or similar for other distros) and throwing in a couple of patches before `makepkg`-ing it is the easy part. Of course you could do it manually, but then what's even the point besides bragging rights. Very few people have a reason build a completely custom system LFS style, and those that do will.
The Linux kernel comes with thousands of different drivers for all kinds of devices which adds weight and such that even slows bootup times. For the home user, sure, default works best.
Why use a kernel with bluetooth modules, wifi modules applied when the actual server has none of that hardware? Not forgetting added security risks. It's all clutter and bloat that's not needed at all.
Do you really need to support a 1998 3Com IPX network card on your production server?
It's about understanding the system as a whole not just the userland or /etc/. Sysctls parameters and fine tuning the cogs that drive the system; the Linux IP stack is abystmal without tuning.
The default kernel works, but your not going to get near best performance without fine tuning and minimalizing the kernel. It's not a bragging excercise, it's a real excercise to ensure the system is secure and to ensure smooth operatation. You'll find these excerised in enterprises where such performance are a requirement.
Knowing how to compile your kernel is key piece of important knowledge to know and you'll find that someone with that knowledge will end up getting hired than someone without.
The saying is true: SysAdmins treat servers like pets; developers treat servers like cattle.
Sure you can dive into that rabbit hole and fine tune your kernel, but then you're on the hook for security patches when you could've just enabled livepatch on Ubuntu Server and been done with it.
That's just lazy if your waiting for systemd to report you a failure. It's on you to maintain, ensure it's all operating correctly; including the daemon starting and stopping manually correctly.
Makes sense that on machines I've inherited that such checks are not done.