Re: If Linux Is About Choice, Why Then ...
On Sun, 9 Apr 2017 08:20:16 +0900
Joel Rees <joel.rees@gmail.com> wrote:
> On Sat, Apr 8, 2017 at 4:15 PM, <tomas@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
Reply to: