Re: Proposal: A config file for runlevels (DRAFT)
>
> So "inetd" is a client-process in that sense? It would be nice if you
> could give the exact criteria for a package to belong in runlevel 2 or 3.
Well, that sounds like a reasonable suggestion. inetd is
required for various client connections to the machine, but it
also potentially enables services required by clients. I'm sure
we can come with a reasonable definition if we all work together.
The client run level should have everything needed to be a
client. If that means running some "server" daemons that client
daemons depend on, so what? I didn't think it needed to be
strictly or explicitly spelled out, but rather that package
maintainers should understand the general purpose of the run
levels and use their best judgement. Remember, these would only
be defaults anyway as the user would have a tool(s) to manage
this stuff in a straight forward manner.
As far as getting run levels understood, I once taught an "Intro
to System V Unix" course at another job to help a crosstraining
effert. PC users understood it, as well as Mainframe operators.
Both groups preferred the idea of controlled system states (i.e.
run levels) over rc.local styles administration. One of these
guys put together an autoexec.bat file with a menu that selected
a system profile which mimicked the SysV init approach on a DOS
system. The K* and S* stuff went pretty smoothly, but we didn't
get too involved in it. I can see that getting confusing, but it
would be our job to provide a layer of abstraction so that people
wouldn't need to get their hands that dirty unless they wanted to.
I'd like to continue this on the admin list you mentioned. Can
you send me subscription instructions?
Thanks
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: