From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: news.groups
Subject: Re: RFD: comp.os.386bsd.{announce,bugs,devel,misc}
Date: 24 Nov 92 02:31:29 GMT
	<CGD.92Nov23155206@eden.CS.Berkeley.EDU> <By75v5.LFx@ra.nrl.navy.mil>
Organization: Kernel Hackers 'r' Us
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: atkinson@itd.nrl.navy.mil's message of Tue, 24 Nov 1992 01:37:53 GMT

why do i do this to myself?

In article <By75v5.LFx@ra.nrl.navy.mil> atkinson@itd.nrl.navy.mil (Randall Atkinson) writes:
=>  The whole POINT of the 6 month rule was to prevent the same bogon
=>newsgroup proposals from being recursively raised.  I recall the
=>guidelines quite well as I date from the days before the Great
=>Renaming and have had a hand in the Guidelines from time to time. 
=>
=>  This silly proposal you are raising again has been discussed and
=>shot down at least 3 times that I recall and is clearly a violation of
=>the 6 month rule.

take a look at the frigging rules.  it very well might be that your age
would prevent you from reading them...  If so, have someone read them to you.
BUT READ THEM.

THIS PROPOSAL HAS NOT BEEN BROUGHT TO A VOTE.
Therefore it *can* be raised again.  to quote, from the Rules:

> [ ... ]
>The Result
>
> [ ... ]
>
>5) A proposal which has failed under point (3) above should not again be
>   brought up for discussion until at least six months have passed from the
>   close of the vote.  This limitation does not apply to proposals which never
>   went to vote.

This is the second time i've shown this to you...  do you have that hard a
time understanding it?

=>>>1) wrong name.  Should be	comp.unix.bsd.i386.*
=>>
=>>	not true;  386bsd is becoming less and less "bsd" as days go by.
=>>	not only that, there are other bsd variants for the i386 which are
=>>	*not* 386bsd and for which 386bsd discussion does *not* apply.
=>
=>Bullshit.  The other variants are almost entirely identical in source form
=>and vary in something less than a dozen files in the entire OS.  386BSD
=>is almost entirely derived from the 4.3 BSD distribution from CSRG and hence
=>is most certainly a fairly generic BSD port.  As to claims that it is
=>less "bsd" this is certainly not supportable in terms of existing postings
=>or source releases or even the name that the OS is called.  If it weren't
=>BSD it wouldn't have been named "386bsd".

Ahh, but, as i asid, "becoming".  You obviously know nothing of the 386bsd
effort; as of the next version, it will have completely different VM system,
will probably have shared libs, will probably have a different method
than the "bsd standard" of autoconfiguring devices, and a host of other
kernel changes.

As i said:  It's a BSD derivative, but it is an operating system in
its own right, and *IS* increasingly divergent.

=>  All of the discussion regarding 386BSD is also applicable to BSD/386
=>(from BSDI) in its entirety with no exceptions.  Don't ignore the
=>reality that BSDI distributes FULL SOURCE with each license and so
=>every single one of those folks can (and most do) use pieces and parts
=>from 386BSD.

And the converse is true as well.  Some fixes to the 386bsd drivers have
been derived from the publicly-available BSDI patches...

But the point is:  That is (not-so-)slowly changing.

=>  Heck, the BSD on SPARC work is largely the same as the 386BSD stuff
=>modulo assembler stuff underneath and small variances for chip
=>architecture in a very small handful of files.

see above.  reread above.  understand above.

=>>	finally, 386bsd is *NOT* unix
=>
=>  Nonsense.  This is reality.  BSD is a popular kind of UNIX and
=>everyone here understands that.  It most certainly is UNIX.  If it is
=>placed anywhere but under the comp.unix.bsd* tree the name won't be
=>appropriate because newcomers won't find it where it is expected to
=>live -- along with the other UNIX versions.  
=>
=>  The legal argument against comp.unix.bsd* is specious because of the
=>large number of UNIX variants (e.g. ultrix) that don't license the
=>trademark and have lived under comp.unix for many YEARS with no
>quibbles from anyone.

I agree.  But you seem to be a member of the FNP (Fascist Namespace Police, for
those who don't know...).  Surely *you* of all people wouldn't let this slip
by.  It would be horrible, and confusing.

=>>>2) ~.devel is gratuitously unconventional.  ~.programmer would be better
=>>
=>>	on 386bsd, almost everybody *has* to be a programmer.
=>>	what we're pushing for is a forum to discuss kernel development,
=>>	not general 386bsd programming.
=>
=>  Then name it ~.kernel so that the name at least makes sense to first
=>time net.folks -- the whole point of naming is to make it easier for
=>newcomers to find the newsgroups relevant to their interests.  Your
=>proposal violates that and common sense.

sorry, i guess that point is more or less yours, because i slipped and gave
it to you.  .devel would also be a forum for discussion of other major
development topics as well.  for instance, shared libraries (which can be done
completely outside the kernel).

=>>>3) The bugs newsgroup already exists:  comp.bugs.4bsd
=>>>   and the proposed group has the wrong heirarchy and so if anything
=>>>   were created it should be named comp.bugs.4bsd.i386
=>>
=>>	again, the 4bsd hierarchy/classification is becoming increasingly
=>>	incorrect.  If it is not completely incorrect now, it *will* be,
=>>	a year from now.
=>
=>  The above is not any kind of answer, so you must be conceding that
=>the original ~.bugs group proposal was malformed.  I'll take this as
=>being a closed item.  Moreover, the bugs in 386bsd are mostly going to
=>be shared in other BSD ports as current postings have clearly
=>demonstrated.  Much of the discussion above also applies here.

you say it well; most of the discussion above also applies here.
386bsd is *NOT* just a standard bsd port, has *LOTS* of bugs which
are (definitely) unique to it, and, as time goes on (see above),
will have even more which apply to 386bsd and 386bsd alone.

=>  A point not mentioned earlier is that most sites cannot implement
=>ANY newsgroup name beginning with the characters [0-9] because of the
=>way the popular news transport software is designed.  Newsgroup names
=>MUST begin with a letter if they are to be implementable at most
=>sites.  This is why we have ~.i386 rather than ~.386 in several
=>places.

This is a reasonable objection.  If someone would help out and provide
*appropriate* alternate name ideas...  (note the definition of appropriate:
something correct for the spirit of the original proposal, and this article.)

=>  If this nonsense keeps up, I'll add other points from time to time
=>as the spirit moves me.

OH MY GOD, HE'S POSSESSED...  (sorry, just had to... 8-)

=>  One would think that after 2 tries, they could at least get the 3rd
=>try to address some of the obvious issues (e.g. bogon namespace) that
=>got this proposal shot down so clearly on the first two times it was
=>proposed but these proposers seem denser than granite.

I was not involved (other than a casual observer) in the first (2?)
RFDs.  I did not notice the numeric naming problem before, but now that
it has been brought to my attention, i'll look into it, and for
alternatives.  Note that the criticisms you have made have not been
of a contstructive nature; you've simply complained, yet offered no
valid (according to our, not unworthy, IMHO, goals).

Please, stop being an obstruction simply for the fun of being
obstructionist, and *READ THE GUIDLINES*.


Chris
--
Chris G. Demetriou                                    cgd@cs.berkeley.edu

"Sometimes it is better to have twenty million instructions by
        Friday than twenty million instructions per second." -- Wes Clark
Xref: sparky news.groups:22193 soc.culture.indian:37313 soc.culture.pakistan:16803 soc.culture.bangladesh:6009 soc.culture.jewish:20213 soc.culture.iranian:10009 soc.culture.arabic:4940