Date: Sat, 07 Dec 1996 23:40:50 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/include utmp.h Message-ID: <765.850030850@time.cdrom.com> In-Reply-To: Your message of "Sat, 07 Dec 1996 12:43:16 MST." <199612071943.MAA27564@phaeton.artisoft.com>
index | next in thread | previous in thread | raw e-mail
> This is simply a matter of allowing someone to make the necessary > changes to seperate the data from the procedures which operate against > it, and seperating the procedures into logical units. Sounds reasonable. So let's talk prototypes. :-) > At the lowest level, this means going to an rc.d mechanism for per > logical unit start/stop/status and ordering. You could support > run levels at the same time, but it's not strictly necessary. I'm not yet convinced that the time is fully passed for further *incremental* improvements to the existing "flat" rc file structure, some of the types of abstraction you're looking for being possible with further extentions to the /etc/sysconfig concept, and without taking the big political hit of arguing for something which smells too much like SYSV for many people's tastes. Please note: I'm not saying that a nested rc.d structure is a bad idea, I frankly don't even care that strongly since I see it as a "six of one, half a dozen of the other" kind of argument. However, past experience has (amply!) shown that anytime you start talking about reorganizing the /etc files and even so much as hint at "rc.d/", you might as well just kiss your proposal goodbye since it's only about to be barbequed in the flame-fest which is sure to follow. Let's start smaller and first separate knobs from labels in the existing stuff, then see where people seem willing to go from there. Jordanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?765.850030850>