Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Tim Watts <tw_usenet@dionic.net>
Newsgroups: comp.os.linux.misc
Subject: Re: What distros *don't* use systemd ?
Date: Thu, 04 Sep 2014 13:03:49 +0100
Lines: 59
Message-ID: <521mdb-1q9.ln1@squidward.local.dionic.net>
References: <lu5np1$u6d$2@dont-email.me> <qetidb-aij.ln1@squidward.local.dionic.net> <lu798e$ofh$1@speranza.aioe.org> <lu8v8d$5tm$1@news1.tnib.de> <gugldb-7gl.ln1@squidward.local.dionic.net> <lu970h$n8p$1@news1.tnib.de> <1jpldb-os5.ln1@squidward.local.dionic.net> <lu9enn$b3g$1@news1.tnib.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 2VQpHcHDaQgbIxVjCutf6AWUpi8Q567ctLqe4uQwW8fMVv7LIg
X-Orig-Path: squidward.local.dionic.net!not-for-mail
Cancel-Lock: sha1:z9ygtMXAm3Z0KUffNv5dB6gtqAE=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
In-Reply-To: <lu9enn$b3g$1@news1.tnib.de>
Xref: csiph.com comp.os.linux.misc:11932

On 04/09/14 11:25, Marc Haber wrote:
> Tim Watts <tw_usenet@dionic.net> wrote:
>> On 04/09/14 09:14, Marc Haber wrote:
>>> Tim Watts <tw_usenet@dionic.net> wrote:
>>>> If that's the attitude of the systemd lead devs, I don't know why
>>>> *anyone* would want to touch it, least of all debian.
>>>
>>> People touch it because there is no serious alternative.
>>
>> init.d/
>>
>> Really - I do not see the problem systemd is trying to solve. Sure it's
>> cute - and it may be adding value/fluffy kittens/administrative ease.
>> But init.d/ is not *broken* and in fact works very well on embedded
>> devices where systemd may well be too heavy.
>
> init.d/ does not handle a bunch of cases that are omnipresent on many
> of today's systems, for example devices, interfaces and IP addresses
> appearing and disappearing during run time.

I see your point and I will counter with:

That should be a stand alone daemon IMHO - like Network Manager - but 
totally independent of any GUI.

If there are dependencies like autofs needs a new config or 
stopping/starting, then starting it belongs to the netman daemon and not 
init.d on an admin choice basis.

However, on servers, the network is usually stable with the possible 
exception of a server2server VPN needing to come up.

> init.d also needs many kludges, such as grepping the process table for
> processes with a distinctly matching name to kill all your children,
> which will in a multi-instance setup inevitably kill other instances
> as well.

This could also be solved incrementally without throwing the whole thing 
in the bin. In fact /var/run/<proc>.pid files are a perfectly reasonable 
approach though it could be made a little more robust against the 
relatively rare case of the process dying and the PID getting recycled 
and pointing at an unrelated process.

I'm not know for being a "dinosaur" but there have been so many efforts 
to rewrite "init" from the ground up and the fact that none have yet 
endured the test of time suggests an evolutionary approach on the 
original method might be more fruitful.


Most of the successes in the unix world have been incremental.

X.org started off from XF86.

Ext4 sits on the shoulders of Ext3 then Ext2 and the latter is very much 
a traditional unix FS.