Date: Thu, 07 Aug 2008 11:29:49 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Jeremy Chadwick <koitsu@freebsd.org> Cc: hackers@freebsd.org, wbentley@futurecis.com Subject: Re: Idea for FreeBSD Message-ID: <489ACE9D.4000606@infracaninophile.co.uk> In-Reply-To: <20080807074332.GA17830@eos.sc1.parodius.com> References: <b58b3fc7f4a07c9b6d55741e2ec25f47.squirrel@secure.futurecis.com> <20080807074332.GA17830@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig19E667A98419EB952FCF3162 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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= =2E >> Basically what it does, is take all the rc.d scripts and puts them int= o >> a database to manage. Everything is converted to XML and two basic >> commands (svcs and svcadm) are used to manage everything. >=20 > I highly recommend you and anyone advocating the use of XML for such > things read the following whitepaper/study, in full: >=20 > http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf >=20 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=20 applications. Which is fine, but as far as I can see doesn't address the= =20 question at hand. =20 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=20 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 prima= ry=20 benefit is in manageability. I would contend that the advantage claimed here is rather less significant than indicated. We already have a centra= l 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=20 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 o= f=20 an rc system -- it's suddenly necessary to have another shlib or two and = several compiled applications available early in the boot process. XML=20 itself is too general-purpose: it has too much baggage designed for its = primary function of facilitating interoperation between diverse systems i= n=20 different zones of control, none of which is particularly applicable to=20 system startup. =20 I can see the attraction of writing a nice pointy-clicky database-backed = GUI management interface to encourage the uninitiated administrator, but = that can only be an adjunct to the current setup, not a replacement. If = you can't fix a broken system via a text only serial console accessed=20 across whatever sort of low-bandwidth emergency connectivity you could=20 imagine, then I suspect quite strongly it's not going to receive=20 wholehearted community approval. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig19E667A98419EB952FCF3162 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiazqMACgkQ8Mjk52CukIzrhgCeNiZUcXPmiXr5yrjJDGF3wQgw 1DcAnRW/wIGfZNIYgTNnePoVV743pU0P =Y15w -----END PGP SIGNATURE----- --------------enig19E667A98419EB952FCF3162--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?489ACE9D.4000606>