On Wed, Jul 12, 2017 at 7:49 PM, David Sommerseth <[email protected]> wrote: > On 12/07/17 18:12, Bruce Ferrell wrote: >> On 7/12/17 5:20 AM, David Sommerseth wrote:
>> I learned it and learned to dislike it even more in that learning. >> >> After five years of dealing with it I'm still bumping into broken stuff >> that is met with >> "why do you want to do that?" for things that worked before, instead of >> fixing the flaw. >> >> The assumption that I either didn't bother or can't learn it is a bit >> condescending... Bruce, lighten up, please. Since you were talking about updating glibc on a CentOS 6 environment, and had expressed dislike of it, advice to bite the bullet hold your nose, and take the plunge into the puddle of gloop is not meant in an insulting way to your competence. >> For me, it has introduced NEW problems and made it difficult to >> troubleshoot them, broken working configurations, and given me no new >> useful functions. > > I am _not_ saying systemd is perfect and without flaws. Not at all! > I'm just saying that my experience is that it works far better than any > other init and basic system management tools I've used over the last 20 > years. And my experience since the early EL7 days and Fedora 19+ days > are that if things which worked under Sys-V/upstart doesn't work with > systemd, it may very much likely be that systemd is not utilized > correctly. Systemd is a paradigm shift within the Linux world. It > requires a different mindset. Umm. When "utilized correctly" means "recompiling systemd and disabling default features", It's a problem. I'm speaking specifically of the "kill all user processes on logout" feature activated in systemd release 230, which broke screen, tux, and nohup backgrounded process with no record of having done so and no way to disable this misfeature except to recompile. There have been others, but that problem was a basic conceptual problem by the primary author of systemd. It's not "not utilizing systemd correctly", it was a horrible misfeature, and there have been too many. The /etc/resolv.conf symlink was another one. Edit the local /etc/resolv.conf with vi and you break the symlink into the systemd managed subdirectory with its own resolv.conf, with no hint that you've just broken DHCP updates to /etc/resolv.conf. That was also nasty. That's not "misusing systemd", that's "systemd breaks the File System Hierarchy by deciding to move /etc/ files elsewhere and replace them with undocumented symlinks. And it had no tool or option to reset the symlink. Systemd is a direct violation of basic UNIX standards such as "wrote one tool to do one task, and do it well". There have actually been such tools for daemon startup management. "daemontools" was very good, lightweight and robust. It ran into licensing issues because Dan J. Bernstein, who wrote it, invented one of the most anti-open-source licenses I've ever seen for his tools. He finally gave up and made them all public domain, but the damage was done. *I* publish RPM building tools for it over on github.com, if you want to see how a good such system can work.
