[1130] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Tue May 7 12:34:21 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Tue, 07 May 1996 12:00:16 EDT."
<9605071600.AA15021@starkiller.MIT.EDU>
Date: Tue, 07 May 1996 12:33:43 -0400
From: "Donald T. Davis" <don@cam.ov.com>
barry writes:
>> I would very much like to see the ability to use *either* db or dbm...
> This is the attitude which has driven krb5 development for a long
> time, and I strongly disagree with it. We should not attempt to
> generalize a solution for every decision we come across, leaving the
> final decision to the sysadmin that will build and install krb5.
> Normal people do not care which database we use, they just want a
> system which compiles easily and works. Giving them an option just
> confuses their lives and makes krb5 even larger and more bloated.
> Furthermore, every time you add a new option like this you increase
> the likelihood of bugs and the difficulty of maintainance...
> We need to choose either to use DB or DBM.
barry's dead right here. this is an example of something
we did a lot at athena, and that mit-spawned R&D shops
generally tend to do. the engineer divides his design
decisions into two groups: algorithmic choices, and
configurational ones. then, the engineer says to himself:
"choose the algorithms, but leave _all_ configuration
choices to the user or administrator." this is ok for
research-grade software, but it's not the way to build an
influential product, unless the product is an erector set.
i think this comes from a tinker's preference for flexibility;
we don't want to lose potential users who don't like the
configuration choices that we make. the trouble is that bloat
and admin-complexity turn away even more users. we want krb
to enjoy widespread adoption, so we have to get out of this
research mindset. the network industry wants and needs a
turnkey security system, not another toolkit.
-don
