Skip site navigation (1)Skip section navigation (2)
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>