-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric MSP Veith escribió: > Sorry to stop you, but I'd plead for some fine-tuning of the dependency > mechanism first (i.e. the dependency OR'ing problem I described in the > channel), before we're going to implement stuff like binary service files and > our own shell or scripting language. (btw, what's wrong with *sh?)
Well, I'm talking of something that we could develop after we have a new shiny core, and after we get rid of the ifiles and other stuff. Until that, dash will make our systems boot faster ;) Binary service files will never be implemented, because they are obscure by nature, but we could implement some caching in the future... > > The more fine-grained or categories are, the more problems we get when we > finally want to sort service files into categories. daemon/ and service/ make > things really clear. Adding "system/" and "net/" brings up only minor > problems that can be solved on a "agreement base", however, if we begin to > introduce more than that we'll end up wasting a lot of time discussing where > a particular file ought to be put into, and it will be confusing for an > outstanding user/developer. Why not Keep It Simple? :-) I think the same. > Perhaps the major task now is to put together a TODO list and marking > priority > items. ;-) > > Eric > > ------ Original Message ------ > Sender: Ismael Luceno <[EMAIL PROTECTED]> > Recipient: [email protected] > Date: Friday 09 February 2007 01:04 > Subject: Re: [Initng] We need to tie /etc/initng > >>> Denis Knauf escribió: >>>> i think, we shouldn't form an opinion about who need a service essential >>>> for startup/shutdown. >>>> we should sort the services by there service. >>>> db databases like postgres and mysql >>>> web http-server like thttpd and ruby on rails >>>> mail mail-services like fetchmail and postfix >>>> net nertwork-provided services like iproute2, pump and ip6table >>>> sys udev and sysctl >>>> snd soundprovider like alsa and icecast >>>> fs mountpoints and 9p >>>> mod special on linux for loading modules >>>> x X-only-related services like entrance and xdm >>>> sec security like selinux >>>> conf your idea with a conf-directory is good :) >>>> >>>> short names and easy to find services. >>> We don't need to distinguish functionality, what we need to >>> distinguish is type. >>> >>> However, that could be implemented inside of daemon/. >>> >>>> by the way: one service per file. >>>> example the hole file of /etc/initng/snd/alsa/mixer.j: >>>> need fs/dev snd/alsa; >>>> env asoundcfg "/etc/asound.state"; >>>> start = { ... [ the long script ] ... }; >>>> stop alsactl -f "${asoundcfg}" store; >>> Well, as i said on IRC, related services should be together, >>> specially if they are useless only. >>> >>>> this was the hole file (but without comments), there's no line, which >>>> sais, that it's snd/alsa/mixer. >>>> for wildcards, i've a second idea: >>>> /etc/initng/mod/default.j: >>>> start = modprobe "${NAME}"; >>> We will be moving to the service_file plugin, and ifiles will be dropped >>> in some future, so there's no point to start modifying the ifiles >>> plugin. >>> >>>> that's all. >>>> >>>> the conf-files we can base on gdbm or like that. faster to use. >>>> second: our i-files are text-based, it's very slow to parse it. we should >>>> use gdbm or a special binary-format with very fast parsing issues. >>> As Jens said, it's fast, so we don't need to improve it, what we need >>> is a customized shell, one that can integrate better with initng. >>> >>> I've been thinking about developing our own language, to make the >>> shell even faster... >>> >>>> i can't code it. i only have many ideas for initng. >>>> >>>> Am Donnerstag, 8. Februar 2007 03:44 schrieb Eric MSP Veith: >>>>> I agree with you, the net/ folder perfectly fits into system/, as Unix >>>>> boxes are network boxes anyway. :-) >>>>> >>>>> Once we've tied the system/ folder, we should change the names/pourposes >>>>> of the services in there as little as possible while only >>>>> adjusting/tweaking the contents of the files. I.e. people should trust >>>>> that system/mountfs stays there, is not renamed and it's pourpose stays >>>>> the same, only the code gets bugfixed and tuned. >>>>> >>>>> So we get: >>>>> >>>>> daemon/ only for daemons, >>>>> system/ services essential for system startup and scripts responsible >>>>> for establishing, maintaining and closing network connections >>>>> services/ place for services that aren't essential for system bootup, >>>>> i.e. "the rest", >>>>> runlevel/ runlevels, >>>>> config/ initng specific configuration files (for configuring >>>>> daemons/services, as /etc/sysconfig or /etc/conf.d do) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFy+wI/mxY0+yOXJoRAju4AJ9wKaVrHRHpUZgnRSRMtvBjOAJ9PQCaA6+K Qq21CMNjyCFkybYMwWHRfa4= =negr -----END PGP SIGNATURE----- -- _______________________________________________ Initng mailing list [email protected] http://jw.dyndns.org/mailman/listinfo/initng
