On 04/10/2017 08:13 PM, Bruce Ferrell wrote: > On 04/10/2017 03:20 PM, Pete Biggs wrote: >>> I must admit that I skipped through the first and second stages - I >>> never found creating init scripts a joy and instead opted to write my >>> own scripts that I launched via inittab. As such, I welcomed the >>> simplicity systemd's service files without fuss. >>> >>> So, at which stage are you in w/ regards to adopting systemd? Are you >>> still ridiculing it, violently opposed to it, or have you mellowed >>> to it? >>> >> It is what it is. >> >> I can see that systemd may not look as straightforward as init scripts, >> but it has been clear for a while that SysVinit is generally not really >> fit-for-purpose. Things like the mystic incantations embedded in >> comments at the top to try and make chkconfig work properly, or the >> lack of a consistent approach to configuring parameters (are they >> embedded in the script? In /etc/sysconfig? The package's own config >> files?). >> >> The fact that there was at one point multiple solutions to the problem >> (with systemd eventually becoming the accepted one) and that no dev is >> really going to voluntarily go through the pain and abuse of >> implementing something new like this shows that it really was thought >> to be necessary. >> >> I think what is/was the issue is the abrasive way that some of it was >> done. It seems to have put people's backs up no end and makes them >> predisposed to find fault with it. >> >> It's just different, that's all. It does the job it was designed to do. >> It even copes with legacy init scripts, so you can still use them if >> you want. >> >> And I remember when these new fangled init scripts first appeared - boy >> did everyone find them confusing and hated them. >> >> P. >> > > My first *IX system had only /etc/inittab and I had to manually add > and configure inetd. Next generation used the bsd init system... > Monolithic. No process start/stop, but I understood it. Then SystemV > came along; Individual processes could be started, stopped, and > queried. The came the function file and THAT was a complete mess... > Every distro developer had his own idea of what functions were needed. > > In all three of those cases, there was a single, simple start up > entity. That was the literal binary program init. It read > /etc/inittab and used that to handle process management and those > management processes were completely transparent. Standardized, well > known locations were used. It was considered to be a not just good > practice, but excellent practice to do so. It wasn't commonly done, > but it was relatively simple to swap between them too. > > The current crop of system initialization systems, do everything > possible to obscure the details of operation... Boot status on the > console? Nope, obscured. Processes logged to standard places? Nope, > someone might hijack the logs (we had a technique for that... remote > logging, but that isn't important enough to make work... Too much > trouble). > > The bottom line seems to be, "I've looked at this, and I know better > than 20, 30 years of experience, so throw it all out and do it my > way"... And if things get broken in the process... Oh well, that's > progress. > > I've had my init system lose communication with the desktop gui and > decide to reboot my system. Yes, systemd did that. dbus got an > upgrade and was restarting so systemd rebooted my system. > > While not directly a systemd problem, I've haddistro builds of apache > that didn't work because of some patch "needed" so systemd could > manage apache (We need systemd hooked so deeply into every process > now?!). Yes, each of these was corrected... But they didn't need to > happen and NEVER happened with earlier init systems. > > The concepts in upstart, launchd, and systemd are mildly interesting > to me and probably more so to others. The implementations of the > ideas have been poorly thought out and tested. They cause so much > trouble for me as to make them worthless to me. When complaints are > registered, the response has often been "if we don't force it, it will > never be tested". Completely unacceptable. > > This is MY issue with the new shiny toy. Heedless and needless system > breakage by an escaped lab rat. And I have to wonder, why in /usr/lib/systemd/system/ is there a file named -.slice ?? Didn't anyone see a problem with this...? or countless possible problems? Doesn't instill confidence.