Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Jun 2012 20:03:56 +0200
From: Daniel Cegiełka <>
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

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.