On 07/12/2017 07:07 PM, Nico Kadel-Garcia wrote:
> On Wed, Jul 12, 2017 at 7:49 PM, David Sommerseth
> <[log in to unmask]> 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.

Yeah Nico, you're 100% right.  mea culpa.  bad week and all and I bit.

>>> 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.
>
I like all of the above