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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?765.850030850>