[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPLrYET49bfBCeT2-jpZbFb5rNrbDB5dh-QwuX_66AccEU6Ptg@mail.gmail.com>
Date: Sun, 10 Jun 2012 20:03:56 +0200
From: Daniel Cegiełka <daniel.cegielka@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
>> 1. On a hobbyist or fully self-maintained system where you're willing
>> to manually do all the work of upgrading/restarting things, or on
>> certain embedded systems where reboot-on-upgrade is acceptable or
>> where you're sure you won't need security updates (because the system
>> does not interact with potentially-dangerous inputs), just start all
>> the daemons from your init script with no management and be done with
>> it. Components should not be designed in ways that _preclude_ this
>> ultra-simple setup.
>>
>> 2. On everything else, use your choice of robust daemon management
>> tool that starts daemons as direct children and therefore can observe
>> their death and/or intentionally kill them without any race
>> conditions.
>
> But with pushing something new we should really understand that it will
> not become a second 'systemd'.
> Thank you very much for explanation.
Do we have some conclusions? systemd+udev is resource hungry, so the
question is, what next? Do we have to think about preparing a new
solution?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
