On Sun, 9 Apr 2017 08:20:16 +0900 Joel Rees <joel.r...@gmail.com> wrote:
> On Sat, Apr 8, 2017 at 4:15 PM, <to...@tuxteam.de> wrote: > > [...] > > What systemd brings (mainly[1]) to the table is the decoupling of > > different "parts" of init: just imagine you have one service (let's > > say a web server) which depends on some other thing (say a file > > system being present via ummm... NFS, but it could be a RAID or a > > memory stick, you get the idea). With a SysV init you can't express > > that: you would have to script it explicitly. With systemd you > > can express that the web server is only to be started once that > > file system appears. > > Well, sure you could express such relationships in the sysv scripts, > and people did. > > But sysv scripts used the shell as the declaration language, and the > shell is very flexible, and everyone seems to have done their own > thing in expressing such relationships. That made it hard to get an > overall analysis. > > What could have been done here was to build a simple database of > relationships and a daemon to maintain the database. Sysv could start > that daemon early, and other inits could simply register through that > daemon as they came on-line. > Someone correct me if I'm wrong, but I run sid and see things come and go. Didn't we have this: https://wiki.debian.org/LSBInitScripts long before systemd? And I have a memory of needing to add this information to a firewall script I made from a template from a very early version of LFS, on some version of stable. The date on the script is July 2011. Besides, I think the main points of contention about systemd are not its init, but all the rest of the baggage that comes with it, particularly the non-text log files. There does not seem to be a compelling non-political reason for moving away from text files. -- Joe
