DragonFly BSD
DragonFly kernel List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: configuration files


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 12 Dec 2003 12:33:42 -0800 (PST)

:This kind of argument (and I don't mean just the last statement)
:comes up often, so let's think about it this way:
:
:There are improvements from the OS point of view, and there are
:improvements from the user's point of view.
:
:One can argue that all improvements to the OS are ultimately
:improvements from the user's point of view, but not all
:improvements from the user's point of view are improvements to the
:OS.  Some are, however, necessary.
:
:Examples of each case:
:1) Bug fixes, better performance, etc. improve the OS and
:   ultimately improve the user experience.
:2) A genuinely cool idea like a MySQL backend for /etc with
:   triggers that SIGHUP daemons improves the user experience,
:   but does little to help the OS.
:3) Device support improves the users experience, and is necessary
:   for usability, but certainly complicates things for the OS.
:
:This is not a statement against improving the user experience, just
:a short reminder that the should at least OS come first...  Or to
:paraphrase, "Ask not what your OS can do for you, ask what you can
:do for your OS."
:
:Just my opinion (but hopefully a well thought out one),
:
:-Paul.

    I think, ultimately, what matters is how things improve from
    a sysop's functionality and ease-of-use perspective.  It's all well
    and fine to talk about the capabilities of XML, but there's no point
    if the capabilities aren't useful for the particular real-world task
    being contemplated (or, more to the point, more useful then what we
    could get out of RCNG's existing capabilities).

    RCNG is a great example of this.  RCNG already had the ability
    to 'start' and 'stop' subsystems, and RCNG already contains all
    the dependancy information required to deal with dependant subsytems.
    But how many people do you know actually go to the trouble of CD'ing
    into /etc/rc.d and running ./blah start and ./blah stop on a regular
    basis?

    Even though it is not difficult to do the above, from an ease of
    use perspective there is a huge difference between doing the above
    and doing, say, a one-line 'rcstart subsystem_name' command as root.

    But in less then a day I was able to make significant improvements
    to the use of the meta-information embedded in the RCNG scripts
    which enables rcstart/rcstop (and future work) to take advantage of
    it in a manner that presents a simple, straightforward, 'easy to use' 
    interface to the user/sysop.

    XML would not make any of this work any easier.  No matter what form
    the data is in, you still have to process it in a manner that benefits
    the target function.  In the case of RC stuff that means dealing with
    fairly complex dependancy graphs.  In fact, XML would make the work
    a whole lot harder.  I wonder how many of you have actually *LOOKED*
    at the files in /etc/rc.d ... some of those scripts do rather complex
    things that really can only be done in a shell script.  XML would only
    add unnecessary layers of complexity and not actually allow us to 
    remove any of the existing complexity.  Another example:  half the RCNG
    scripts do not support 'stop'.  Reimplementing in XML would not magically
    cause 'stop' to be supported.  In otherwords, you still have to do the
    work required to implement the 'stop' function for those subsystems that
    do not have it.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]