From: davidsen@ariel.crd.GE.COM (william E Davidsen) Subject: Re: RFD on splitting comp.os.linux Date: Wed, 2 Jun 1993 16:50:15 GMT
In article <1u998m$hdo@cs.ubc.ca>, edmonds@edmonds.home.cs.ubc.ca (Brian Edmonds) writes:
I'd like to say that I believe the posting rebutted below is an
eggregious case of wishful thinking.
We do not have a choice of having this discussion in a Linux group or
not, we have a choice of having it in its own group or the misc group.
Voting down a group won't make the postings go away, so all the
suggestions that the discussion be moved out of the linux heirarchy are
totally pointless, as are comments that everything a true expert ne4eds
is in the FAQ.
The only choice is whether we have a group for certain questions or
have to wade through all of them every day. That is the only choice we
can make. I will vote for a group to hold every type of question I
don't want to see, just to reduce the number in the groups I read.
| mdw@TC.Cornell.EDU (Matt Welsh) wrote:
| > comp.os.linux.admin
|
| Linux administration is exactly the same as any other unix. No two
| unices are administered exactly the same, but Linux seems to be as
| standard as you get.
I've admined SunOS, hp-ux, Xenix, SCO UNIX, Dell V.4, Convex and
Ultrix a little, Sys-III (PC/ix and 68k based), and the PDP-11 versions
of V6 and V7. Sysadmin is not the same on any other these as it is on
Linux. Moreover, admin between various incarnations of Linux, such as
mcs and SLS, is not exactly the same due to selection of various options
and versions of packages.
Anyone who sees Linux (pick your version) as "exactly the same as any
other unix" obviously never looked closely at any UNIX or clone thereof,
even at the gross level of "does it use shadow password" or "where are
the net config files kept?"
|
| > comp.os.linux.apps
|
| The LSM project should cover pretty much anything I can think of this
| group being used for. One person has suggested using it for porting
| questions, but almost everything these days compiles out of the box.
That may be true if "almost everything" is at the "hello world" level,
but a quick look at the work which went into making "make linux" work on
common network packages will convince anyone who is remotely unbiased
that there are required changes for virtually every application of any
useful size.
| What with all the binaries available these days, the people who are
| actually doing the bit of serious porting still occasionally needed are
| not the ones who would come to co.linux for help.
The idea that everything useful has always been done belongs in the
same cesspool with the idea that "no one will ever need more than 640k
on a home computer."
|
| > comp.os.linux.SLS (etc)
|
| Any installation questions on SLS (et al) should be (and I expect to a
| large degree are) covered in the documentation that comes with the
| package.
Would you please take a year and write this great documentation,
keeping it up to date, and commit to keeping it current? Then the
traffic on this topic will naturally dwindle to nothing as the need
vanishes. Sounds about as likely as as Clinton saying he will not be a
tax and spend president.
| Any bugs found should be reported directly to the maintainer
| of the distribution, who can then make periodic fix reports to cola as
| necessary. (In other words, someone who cannot think of a better place
| for porting help than co.linux should perhaps consider an easier
| project.)
Reread my fist statement. We have the choice of *where* these postings
go, but we can't make them go away. Anyone who doubts this should look
at the history of the net, even back before the great renaming. "Those
who fail to learn from history are doomed to repeat it."
|
| > comp.os.linux.bugs
|
| Generally, bug reports should be made directly to the author/maintainer
| of the code in question. It's not as if cola has too much volume
| currently to support a few more bug fix announcements.
There's a bit of truth to this, but a lot of stuff in bugs is going to
be unexplained behavior, with no clear indication of which part of the
system is at fault.
|
| All in all, I don't remember seeing one new group proposed that could
| not be handled better by the old adage of "think before posting."
For the last time, the issue is where we put the stuff you don't want
to see, not how to ignore it and hope it'll go away. It never has in the
history of the net, so let's create the subgroups now and avoid
cluttering the misc group. We should really create a group for
discussion of reorgs, too.
| PS: I'm not following the Linux RFD in news.groups, so if anyone has
| followup to this specifically directed at me, please send me a copy
| in email.
I somehow doubt that I'll ever convince you, but fortunately I only
have to convince 2/3 of the readers who's minds are not made up.
--
bill davidsen, GE Corp. R&D Center; 518-387-6489
Look for a new corporate affiliation, coming to this space soon.