On Sat, Jan 23, 2021 at 06:41:39PM -0600, ~Stack~ wrote:
> 
> TL;DR synopsis.
>

Mr. Stack, Sir! Thank you for writing up this historical overview,
I read it with great enjoyment. Of course I have a few comments.

> It's just a tool.

I feel blindsided by this systemd business. I cut my teeth starting
with SGI IRIX circa 1992, and I am well aware of the shortcomings
of SysV init scripts. I am also well aware and I celebrate it's main
feature. Any and all problems I ran into could be fixed in a couple
of hours using "vi". (hack the bad script until it works).

So years later, "upstart", etc start showing up and I thought "whatever...",
it cannot be worse than SysV scripts. And sure enough. (SL4, SL5, SL6 era).

Then I read in the news this whole "systemd kerfuffle", and I think,
"whatever...", it cannot be that bad, if it is good enough for
Red Hat *Enterprise* Linux, should be good enough for me. Must be a tempest
in a tea pot, another vi/emacs holy war, for sure they will fix all
the bugs by the time I see it.

Then it shows up in all it's glory in SL7, and? With my eyes I see
that, yes, it is as bad as the worst naysayers have proclaimed.

For me, the issues are not policital, but technical:

- cannot ask "what order will you start things on boot?"
- does not start things on boot in the order I specified in the service files
- designed-in chicken-and-egg problem with systemd and dbus each starting first
  and registering with each other
- documentation is for latest version, but my computer has version N-5, half
  of advertised functions are absent
- the infamous bug report about systemd rejecting valid user names (in the nutshell,
  systemd author decreed "I decide what usernames are valid" and closed the bug)
- broken-out-of-the-box, "shutdown -r now" does not shutdown "NOW!!!". Tries
  to logout interactive users, unmount NFS filesystems (after shutting down
  the network), waits until programs users run in background terminate).

By this list, clearly, basic debugging and basic system operational needs
are not important to the systemd designers and developers.

And I guess it is all my fault, I should have rooted for the right team
back in 2002 (or whenever) on the Fedora and Debian mailing lists.
Instead, I was asleep at the switch, being a happy user of SL4/5/6.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada