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