Date: Mon, 02 Feb 1998 12:13:36 +1030 From: Mike Smith <mike@smith.net.au> To: Adam Turoff <AdamT@smginc.com> Cc: "'mike@smith.net.au'" <mike@smith.net.au>, Karl Pielorz <kpielorz@tdx.co.uk>, config <config@FreeBSD.ORG> Subject: Re: FreeBSD updated Installation / Adminsitration Kit Message-ID: <199802020143.MAA00990@word.smith.net.au> In-Reply-To: Your message of "Fri, 30 Jan 1998 15:19:00 PST." <34D25FB6@smginc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Get over it. Microsoft spent gobs of money coming up with a set of > > rules that result in an interface that's easy to use. There's nothing > > dishonourable in stealing their ideas. > > After all, they stole most of their ideas, anyway. :-) That's not really fair. They bought at least some of them. 8) > [bobbit] > > > 3. We write something that tries to accomplish both the above, > > > hopefully not causing too many compromises. > > > > This would be a major layering mistake. > > I don't know about that. There are two interrelated issues here, as you > point out. First, we need a virgin installer to get FreeBSD on new > hardware. > That should leave a system that can be admined by something more > friendly than cryptic UNIX commands documented over $100 worth > of O'Reilly titles. THAT will help evangelize FreeBSD IMNSHO. Yes, but the two are not the same thing. Yes, they *will* sport a lot of the same component functionality. > > > SO - Yet again, I'm asking: > > > > > > a) Who's up for this? > > > > Yes. > > Ditto. Thanks; please stay around, and keep bouncing those ideas everyone. > > Read Netscape's LDAP developer pages, and work out how to talk to an > > LDAP server from Netscape. Start thinking (and talking) about how to > > tie all this together. > > OK. I did this in August, and barely made heads or tails out of it. > What I > got out of it was this: LDAP, like XML and SQL is an enabling standard > that makes complex things simpler and more approachable. > > Is that a good soundbite definition? Not really. Look at it this way: LDAP provides an efficient opaque parameter storage mechanism. It is network-friendly, can be secured, and a proven and reliable implementation already exists. An extra bonus with the UMich LDAP server (the one we are likely to use) is that parameters are actually handled by backends which can be added to the server. This means that you can make, say, the parameter space exported by Juliet (which corresponds to stuff scattered over the system's configuration files) appear inside the parameter space managed by the LDAP server. One parameter access method to rule them all, and in the darkness bind them. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802020143.MAA00990>