Subject: Re: HSM deisgn goals was: RE: HSM implementation proposal
To: None <mjacob@ns.feral.com>
From: Ty Sarna <tsarna@endicor.com>
List: tech-kern
Date: 12/06/1997 15:42:47
Matthew Jacob wrote:
> 
> I'm sorry- the problem I'm having here is really a dissatisfaction
> with the negative attitudes of various conflicting so called 'free
> software' groups. The attitudes of general purpose disdain that I
> perceive rather than an attitude solving problems using whatever
> resources and ideas seem even possibly good are beginning to get to me.

OK, I can see that.  I am frustrated that BSD people seem to have more
trouble getting along with each other than everyone else.  We've already
split into 3 BSD's, and even so there *still* isn't enough room for all
the different personalities to get along.  I know of at least two
important people (eg core members, port-masters, and such) in NetBSD
who aren't on speaking terms with each other. That really appalls me.

On the other side, I'm having some trouble with proposals that from my
point of view looklike they're trying to turn Unix into something it
isn't.  There are several systems I like, such as the Amiga, BeOS, etc. 
Unix isn't what I would have designed for an OS.  But, I strongly
believe we need to try to enhance any given OS, rather that try to make
it look morelike a different OS.  That doesn't mean certain features are
necesarily bad, but they need not to be taken out of context (eg, X OS
has Y feature because of the way it does Z.  If we do Z differently, Y
feature may be completely inappropriate).  I want tomake sure things are
designed in keeping with each OS's philosophy.  For example, if I were
thinking about HSM for AmigaOS, the design would be *completely*
different.  It would be a single handler (VFS-type-things), rather than
something else with a user server process. 

That's where I'm coming from.

That's not to say that we shouldn't look to other systems for ideas,
just that we want to keep the above prominently in mind.  There are in
fact a few things I (gasp) like about Windows.  INI files, for example. 
The idea of a common, human-readable and machine-(re)writable format for
configuration files is a great idea.  The closest thing on Unix is the
"cap" format (termcap, gettycap, printcap), and frankly, it sucks by
comparison.  But, since there's no clear mandate or justification for
converting the hundreds of configuration file schemes used on Unix, I'm
not trying to get anybody to switch to .INI files.  I do have my own
library that implements somehting similar (but with IMHO a much better
API and some very small format enhancements). But, I don't use it for
things that there's any chance of getting into NetBSD.

Like the idle daemon I recently wrote -- I don't know if anyone would
want to integrate such a thing into NetBSD, and it's not in a state
that's it could be anyway (has a lot of site specific stuff that's
difficulat to modularize out well), but I use the getcap() routines for
the configuration for it (since it is is the closest thing to a
standard, and since the routines are already there)

For stuff that's cross-platform, or that is already un-Unix-like in
design or purpose, I go with my INI-like stuff, since I think it's
superior. 

> I'd like to apologize to everyone for my bad attitude about this- I'll
> back away and go work on other stuff for a while and come back later.

I maybe have had a bad attitude about some of the more...  well, to my
way of thinking "extravagent" proposals that have been made, and I hope
I didn't offend anyone.  I know sometimes we all get a little carried
away with our enthusiasm for a certain position, and I'm sorry if I did
that.