[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120612154646.78c592e6@sibserver.ru>
Date: Tue, 12 Jun 2012 15:46:46 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
Some compromise can be reached here:
- User wants runlevels, boot profiles, etc... - a daemon that started
by minimal init can be developed,
- User do not wants runlevels, his/her system is controlled by, for
example, shell scripts - then daemon is optional, init starts shell
script that will boot the rest system (as ninit does for example)
Daemon must not be overfeatured, must be highly configurable and
controllable, and should target only few platforms (generally only
platforms that use Linux as kernel). Daemon should not control hardware
status, this is a mdev/udev's job. Ideally, as udev/mdev is for
hardware, than this daemon is for processes.
Both daemon and init can be a part of one package, and when installing,
user should be able to select, which components it wants to install
(install daemon or not).
Init is critical process - when it dies, then whole system becomes
unusable.
Ideally init must not do anything than reap orphans/zombies, but
starting shell scripts does not require init to be expensive, so it
should be implemented too. Adding anything not related to this job to
the init will be the future source of undefined behavior and fatal
errors.
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.
