On Tue, Jul 30, 2013 at 5:12 PM, zxq9 <[log in to unmask]> wrote:
> On 07/30/2013 10:26 PM, Tom H wrote:
>>
>> On Tue, Jul 30, 2013 at 8:24 AM, Nico Kadel-Garcia<[log in to unmask]>
>> wrote:
>>>
>>> On Tue, Jul 30, 2013 at 8:18 AM, Tom H<[log in to unmask]>  wrote:
>>> Thanks, good link. I'm just concerned it's going to cause build
>>> problems for *every single open source daemon* as their SRPM's or
>>> .spec files need to have two sets of options, one for the older SysV
>>> init scripts and one for systemd, or need to be split to two different
>>> .spec files. This is going to be so much fun!
>>
>>
>> You're welcome.
>>
>> Very true. Similar to some current Fedora spec files:
>>
>> %if 0%{?rhel}
>> ...
>> %endif
>> %if 0%{?fedora}
>> ...
>> %endif
>>
>> An eyesore and a mess; until December 2020...
>
>
> tl;dr, Relevant Fedora thread first:
> http://lists.fedoraproject.org/pipermail/devel/2012-October/thread.html#172159
>
> Reminds me of a dismal post from October:
> http://zxq9.com/archives/711

Yes. It's too bad that dismal poster didn't actually know more of the
history and types of daemon managers. SysV init scripts, which are
what that article so casually refer to as "*nix", are actually a
massive upgrade from the old /etc/rc.local setups. But there are
problems with them: they don't maintain the states of daemons that are
likely to crash and need restart, they're used inconsistently and
erratically, and their output is not logged reliably when they're run
as a root user. So there are a compelling set of reasons to use a
better daemon and init process.

i am afraid that the systemd authors have fallen prey to the idea that
their own tool can do *everything* better than the smaller, less
flexible, but more stable and better integrated tools currently used.
NetworkManager and Gnome3 have encountered similar issues, and it
concerns me about what we will inherit from upstream for use in
Scientific Linux 7.