Date: Thu, 7 Aug 2008 20:26:50 +0300 From: Alex Kozlov <spam@rm-rf.kiev.ua> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, hackers@freebsd.org, Jeremy Chadwick <koitsu@freebsd.org>, spam@rm-rf.kiev.ua Subject: Re: Idea for FreeBSD Message-ID: <20080807172650.GA56516@ravenloft.kiev.ua>
next in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080807172650.GA56516>