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.

>> 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.