Re: Four people decided the fate of debian with systemd. Bad faith likely
On Sat, 01 Mar 2014 19:30:08 -0600
yaro@marupa.net wrote:
> For example, initscripts are so VERY not portable. I am sorry to say this, but
> it is true. In theory they should be, as you state, according the UNIX
> Philosophy they should be. But here comes the problem of that philosophy
> assuming every UNIX/UNIX-like works the same and has the same tools.
Since many distos went to systemd, now in fact it isn't so important to
be portable, isn't it? On the other hand, initscripts are quite
portable inside Debian, i.e. to alternative kernels (KFreeBSD, Hurd).
> In a VM, you should try copying a Debian initscript into another SysV-using
> Linux distribution. It doesn't work. Portable initscripts just don't happen.
> Would be nice, but they don't.
> Another reason this is good is notice how much time you'd have to take to
> figure out what, exactly, the initscript is doing. Is it starting the daemon
> yet? Or is it still laying the framework? Why is it doing things that way?
>
> While in unit files you may wonder what one option is, it's a quick man page
> away, but initscripts will require good documented code and a reasonable skill
> at reading the language.
That's because init scripts were from beginning written without real
planning and every distro was taking into consideration only it's own
situation. But besides this, it would be much simpler to fix this then
make systemd.
> Let's go over the fact it's a nightmare to debug initscripts and they still
> frequently hit failures such as losing control of their associated daemon.
> That's bad.
Init script doesn't need any control of the associated daemon. If
software crash, then you need to fix the software, and on other hand,
it's simple to write monitoring shell scripts that will restart crashed
processes, but it's dangerous because crash can disturb something and
restarting your server after crash without analysis of the situration
can make bad cosequences (data damage/loss, security holes...).
> Systemd basically fixes some problems and also adds a few features I think
> Linux has been in desperate need for: Concurrent dependency launch, reliable
> process control, the journal, the udev merge makes sure that things services
> need are available when they need them. It also provides ways to track the
> states of all your units and even look into why they failed. Sadly,
> initscripts usually chuck all errors into /dev/null, which isn't helpful.
startpar already does concurent dependency launch, process control is
quite reliable and only mega-users need something better, neither they
need journal, udev makes you much problems, all you need is to find out
what module to insert for your hardware and community orientation makes
this information easily spread over the whole Linux community.
> Oh, as for portability, the way systemd works means unit files are pretty much
> guaranteed to work no matter where they run provided of course their
> associated software exists. Can't expect Apache to launch if Apache's not
> installed. The only exceptions are probably in cases where a unit might call a
> script or something that presumes a specific configuration.
Not only this, but similarly with shell scripts, dependancies may have
different name in another distro.
Reply to: