[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplifying IKE
All of this is rather tangential to what is really
at hand, of course. I notice that you haven't
responded to the issue I brought up about the
suitability of IKE in situations where user
expectations haven't been set by near-infinite
modem training times.
Mike
Henry Spencer writes:
> On Sat, 11 Aug 2001, Michael Thomas wrote:
> > > No, actually, the Unix/TCP-IP/C stance. Build a decent general-purpose
> > > solution, and most of the people who were complaining about needing custom
> > > solutions will discover that general-purpose solutions really are good
> > > enough...
> >
> > The general unix philosophy is to build small building
> > blocks which can be bolted together too instead of
> > overarching "solutions" (what was the problem again?).
>
> That's *part* of the general Unix philosophy, but not all of it.
>
> Where problems looked diverse and flexibility seemed needed, then yes,
> building blocks and tools for combining them were provided.
>
> But when a single good compromise solution seemed possible, that solution
> was implemented and no alternatives, variations, or options were provided.
> For example, Unix offered exactly one filesystem user interface, and a
> very simple one it was too. This radical simplification (by the standards
> of the time) did wonders for the building-block philosophy at higher
> levels, because there was little room for incompatible views about what a
> file looked like.
>
> Henry Spencer
> henry@spsystems.net
>
References: