Idea for FreeBSD

[Alex Kozlov]

On Thu, Aug 07, 2008 at 11:29:49AM +0100, Matthew Seaman wrote:
> Jeremy Chadwick wrote:
> > On Wed, Aug 06, 2008 at 07:14:51PM -0400, wbentley at futurecis.com wrote:
> >> To who it may concern,
> >>
> >>    I am A FreeBSD administrator as well as a Solaris Administrator. I use
> >> BSD at home but Solaris at work. I love both OS's but I would like to
> >> increase the administrative capability of FreeBSD.
> >>
> >>    In Solaris 10 the Services Management Facility (SMF) was introduced.
> >> Basically what it does, is take all the rc.d scripts and puts them into
> >> a database to manage. Everything is converted to XML and two basic
> >> commands (svcs and svcadm) are used to manage everything.
> > 
> > I highly recommend you and anyone advocating the use of XML for such
> > things read the following whitepaper/study, in full:
> > 
> > http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf
> > 
> 
> Heh.  Loved all the little asides to Nancy... Amazing it hasn't been
> fixed in 4 years.
> 
> Anyhow, yes: ASN.1 is smaller, and hence faster than XML for networked 
> applications.  Which is fine, but as far as I can see doesn't address the 
> question at hand.  
> 
> There are two connected questions here:
> 
>    * What technology should be used to implement the FreeBSD rc.subr
>      system?
> 
>    * What functionality could or should be added to the FreeBSD rc.subr 
>      system?
> 
> Where the answer to the first question clearly constrains the results
> of the second.  So what are the requirements for the rc system?  Off
> the top of my head -- and I've probably missed some vital considerations
> here -- in order of priority:
> 
>    1 reliability.  The system has to boot up.
> 
>    2 repeatability. The system has to boot up in a consistent state
> 
>    3 fault tolerance.  The system cannot fail to boot up unless the
>      problems really are terminal.
> 
>    4 configurability.  The system has to boot up correctly for all
>      conceivable combinations of hardware and software.
> 
>    5 portability.  Should run on anything from the smallest of
>      embedded devices to the most enormous high power super computers
>      to the most transient of virtualized hosts.
> 
>    6 manageability.  Must be comprehensible by ordinary mortals.
> 
>    7 efficiency.  Must bring the system up as fast as is practicable and
>      without excessive use of system resources
> 
> What does XML-based technology bring to this?  As the OP states the primary 
> benefit is in manageability.  I would contend that the advantage claimed
> here is rather less significant than indicated.  We already have a central
> database of configuration information -- /etc/rc.conf -- and while we don't
> have one single application to control starting and stopping services we 
> have the next best thing: a consistent user interface for calling the 
> individual rc-scripts.  Indeed, as other posters have shown elsewhere in 
> this thread, adding that sort of functionality is only a Small Matter of 
> Programming using the existing tools.
> 
> What's wrong wwith using XML?  XML adds significantly to the complexity of 
> an rc system -- it's suddenly necessary to have another shlib or two and 
> several compiled applications available early in the boot process.  XML 
> itself is too  general-purpose: it has too much baggage designed for its 
> primary function of facilitating interoperation between diverse systems in 
> different zones of control, none of which is particularly applicable to 
> system startup.  
While in general I agree with You, I must note that We already have
xml parser (expat 1.95) for geom. See /lib/libbsdxml.so*


--
Adios