Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!tektronix!peewee!tonyb
From: tonyb@peewee.UUCP
Newsgroups: comp.os.minix
Subject: Re: Future of Minix
Message-ID: <10184@tektronix.TEK.COM>
Date: Mon, 26-Jan-87 16:09:54 EST
Article-I.D.: tektroni.10184
Posted: Mon Jan 26 16:09:54 1987
Date-Received: Wed, 28-Jan-87 07:17:30 EST
References: <521@csun.UUCP>
Sender: tonyb@tektronix.TEK.COM
Reply-To: tonyb@peewee.uss.tek.com (Tony Birnseth)
Distribution: world
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 45
Keywords: future of a useable piece of software

With all this talk about "add this" and "add that", has anyone thought of the
value of this nice public domain OS *AFTER* everyone is done hacking in their
favorite modifications?  Today someone could claim that program x runs under
Minix.  Tomorrow though, Joe X. User writes an application under his version
of Minix and posts it.  Unfortunately, he's added some mods that allow sharred
text, swapping, or demand paged VM.  It doesn't run anywhere else.  Joe claims
that he just laid in messageID 3904765@foobar.edur, if you're behind or didn't
get it, it's your problem.

The reason applications like rn, patch, and other programs are successful is
that they are centrally controlled.  That is, modifications are researched,
tested and distributed by a known channel and approved by a know person(s).
This provides consistancy and a "release" type of upgrade system.

Under old V7 and the later versions of Unix, knowing that a new release was 
up and comming helped prevent too many local hacks from being laid in.  If 
an enhancement is in order, the modifications are sent to the author (or
release manager) of the software to be included in the next "standard" release.
If you've worked in an OS support related environment you'll know what it's
like to have to sort out, test, and lay in all your local mods of the next
"standard" release.  This process occurs every couple of years and usually take
a couple (or few) months to get *your* (the one with all your hacks) ready to
run.

What this is all getting to, is that for enhancements/modifications to Minix to
be useful to the greatest number of people, there must be some coordination of
effort.  This is a very time consuming affair.  

I propose that (before everyones fingers get too busy) there be a means set 
up to archive, test, and implement future versions of Minix.  Results should 
be publicly available so that no one is excluded.  If a request for
modification is turned down, there should be valid reasons and these should
be publicly available.  Additionally the responsibility (or decisions) should 
not rest on any one individual.  A committee (God help us!) or similar group 
of competent people with OS maintenance experience attempt to coordinate 
distribution releases.  Of course, none of this is enforceable nor should it
be.  It would be a voluntary means because a large percentage of the user
base felt it was desireable.

Ideas, suggestions, comments  are welcome.  

Tony Birnseth
tonyb@tektronix.tek.com

P.S. No, I'm not volunteering!