Date: Tue, 02 Feb 1999 09:45:41 -0500 From: Robert Withrow <witr@rwwa.com> To: Richard Wackerbarth <rkw@dataplex.net> Cc: Wes Peters <wes@softweyr.com>, hackers@FreeBSD.ORG Subject: Re: more modular rc/init/uninit system... Message-ID: <199902021445.JAA13206@spooky.rwwa.com> In-Reply-To: Your message of "Mon, 01 Feb 1999 05:59:35 CST." <Pine.BSF.4.05.9902010537570.51597-100000@nomad.dataplex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
rkw@dataplex.net said: :- Actually, more than "on startup". You should be able to move from one :- environment to another at any time by changing the target. (eg run :- level) I think it is important to avoid conflating "configuration management" with "startup/shutdown" management. The SYSV run-levels do that and I think that is a great flaw. I'd like to separate these two things. So, for example, deciding whether to start PPP over your ISP or Ethernet over your office LAN would be a "configuration management" issue. Actually starting the system, given a particular configuration, would be a "startup/shutdown management" issue. That is not to say that the one wouldn't draw on the features of the other. For example, should you decide to switch from one configuration to another without restarting the system (by sleeping your laptop at the office and waking it up at home) you would presumably use the "startup/shutdown management" features to stop/start/restart the appropriate services to effect the switch to the new configuration. Keeping a strict demarcation between these two entities will result in a much simpler and thus understandable/maintainable implementation than a mongo-ronco-Makefile-prolog-rule-based-config-rewriting does-everyting tool. IMO. My proposal carefully addressed only the startup/shutdown management issues, leaving the configuration management issues to some other to-be-designed-in-the-future tool. --------------------------------------------------------------------- Robert Withrow, R.W. Withrow Associates, Swampscott MA, witr@rwwa.COM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902021445.JAA13206>