vote on new group UTS
Stephen_Sh...@cup.portal.com
UTS is Amdahl's implementation of AT&T system V UNIX. It has been
around for more than 10 years! It runs on system 370 architecture.
Many IBM installations use UTS instead of AIX...
The news group can be used as a place to discuss UTS related topics.
Please vote YES or NO... give me some feedback if you like.
--Steve Leung
le...@cup.portal.com
Stephen_Sh...@cup.portal.com
I posted a news on news.announce.newsgroup on 4/2/90 to call
for discussion on creation of a new newsgroup "comp.unix.uts".
I was informed by news authority to follow the correct procedure to create new
news group. First we should have discussion then the voting.
All follow-up to the discussion should go to news.groups.
The discussion period is 4/2/90 - 4/27.
The voting period is 5/1/90-5/25.
I propose the following:
name of the new group = comp.unix.uts.
nature = unmoderated
areas = any UTS related topics. E.g. available software, bugs, tips, helps
etc.
I need 100 YES/CREATE votes to create the new group.
I will post a mail after the end of the discussion period to ask for
the voting.
Please send the follow-ups to this discussion, NOT to me; so everyone
knows what happens.
There won't be a comp.unix.uts unless I have your participation.
Let's make UTS a better UNIX.
Steve Leung
le...@cup.portal.com
Tom Littauer
Obviously I'm biased... I think that UTS is a great topic for a newsgroup.
Given the nature of our business, however, it's unlikely that we're gonna
have a mass appeal: at 3/4 $Million and up per system there aren't a lot of
systems administrators who'll leap on this. Obviously we could fake it by
asking all our developers to vote yes, but that'd be contrary to the sense
of the netiquette rules (even if not to the letter).
Perhaps the right thing to do is to create a newsgroup dedicated to
mainframe-class UNIX systems, by which I mean systems which:
a) can handle terabytes of <= 20 ms disk
b) can handle thousands of userids
c) can handle many hundreds of terminals
d) run native on mainframes
e) do useful work under all the above conditions
There's precedent for naming a newgroup about a class of systems for the first
of that class; since UTS has been around meeting the above rules since 1985
(in production since 1978) we qualify... but we wouldn't object too much if
a more generic name were suggested. After all, to do otherwise wouldn't fit
with the UNIX tradition, and as a real UNIX company we wouldn't have it any
other way.
Well, enough rambling... I guess what I'm suggesting is:
1) Mainframe class UNIX systems are an important topic, especially to people
who believe in Open Systems but have huge problems to solve.
2) Dollar volume purchases and numbers of critical systems implemented are
as large as the mass-market systems, although the people involved are
fewer in number.
3) Given all the above, I don't think the proposed newsgroup can pass even if
*ALL* the people critically involved vote for it; nevertheless I believe it
to be an important group. Is there a mechanism for groups like this to
be created?
Please continue discussion on this here in news.groups.
Thanks,
Tom Littauer
--
UUCP: litt...@amdahl.amdahl.com
or: {sun,decwrl,hplabs,pyramid,ames,uunet}!amdahl!littauer
DDD: (408) 737-5056
USPS: Amdahl Corp. M/S 278, 1250 E. Arques Av, Sunnyvale, CA 94086
I'll tell you when I'm giving you the party line. The rest of the time
it's my very own ravings (accept no substitutes).
Peter da Silva
I've been thinking that comp.unix needs some cleaning up for some time.
There's a fair amount of confusion over where a given article should go:
is it too complex for comp.unix.questions? Is it hairy enough for .wizards?
These groups have become like tweedledum and tweedledee over the years,
with hardly any difference between them. The volume in .questions is just
a little higher, that's all.
The following suggestions are a mixed bag, intended to stimulate
discussion rather than be treated as a concrete proposal.
comp.unix.misc Miscellaneous UNIX discussions (formerly .questions)
comp.unix.apps Third-party UNIX applications.
comp.unix.wizards As now.
comp.unix.intel286 80286-based UNIX discussions (formerly .microport)
comp.unix.intel386 80386-based UNIX discussions (formerly .i386)
comp.unix.xenix As now.
comp.unix.sys5 General System-V stuff.
comp.unix.bsd General BSD-stuff.
comp.unix.clones UNIX lookalikes (Coherent, MINIX, etc...)
comp.unix.big-iron UNIX on Big Iron (formerly comp.unix.cray)
comp.unix.digest Moderated UNIX discussions (formerly comp.unix)
comp.unix.moto68000 UNIX on 68000-based PCs (Mac, Amiga, etc...)
More simply, how about just creating...
comp.unix.misc Unmoderated miscellaneous UNIX discussions.
comp.unix.big-iron UNIX on Big Iron.
comp.unix.apps Third-party applications (e.g., foxbase, lyrix, etc)
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.uu.net>.
/ \ 'U`
\_.--._/
v
Mark M Mehl
>I've been thinking that comp.unix needs some cleaning up for some time.
>There's a fair amount of confusion over where a given article should go:
>comp.unix.intel286 80286-based UNIX discussions (formerly .microport)
>comp.unix.intel386 80386-based UNIX discussions (formerly .i386)
>comp.unix.moto68000 UNIX on 68000-based PCs (Mac, Amiga, etc...)
Perhaps we might consider starting a comp.unix.cpu.* hierarchy for
them:
comp.unix.cpu.i286
comp.unix.cpu.i386+ (the + means the intel486 is also included)
comp.unix.cpu.m68k
-----------------------------
>comp.unix.apps Third-party applications (e.g., foxbase, lyrix, etc)
I would prefer if newsgroups stayed application oriented so that
Foxbase was discussed in comp.database rather than comp.unix.apps.
I cannot imagine every Unix application on earth being discussed in
*one* newsgroup; sounds like a riot of discussion. Moreover, most
questions about applications are application-oriented ("How do I do
... with this application?") rather than system-oriented ("How do I
install ... on Unix?").
--
/\ Mark M Mehl, alias Superticker (Supertickler to some)
<><> Internet: me...@atanasoff.cs.IAstate.edu
\/ UUCP: {{mailrus,umix}!sharkey,hplabs!hp-lsd,uunet}!atanasoff!mehl
Disclaimer: You got to be kidding; who would want to claim anything I said?
Chip Salzenberg
>I've been thinking that comp.unix needs some cleaning up for some time.
I agree with most of Peter's proposals.
Renaming questions to misc will reduce confusion, as will renaming
microport to intel286 and i386 to intel386.
However, we should *not* have "sys5" and "bsd" groups. No developer
can afford to ignore either environment. They're merging, anyway.
And where would you put mixed bags like HP-UX?
Further, we should *not* have an "apps" group. It would overlap with
groups such as comp.databases and comp.text.desktop. The "misc" group
will cover the proposed "apps" charter.
--
Chip Salzenberg at ComDev/TCT <chip%t...@ateng.com>, <uunet!ateng!tct!chip>
Peter da Silva
> Perhaps we might consider starting a comp.unix.cpu.* hierarchy for
> them:
Well, perhaps, but the CPU isn't the important part. It's the fact that
it's running on a PC that uses that CPU:
comp.unix.pc.i286
comp.unix.pc.i386 (I see NO need to do any magic for '486, and if the
586 is no different, for it either. If the 686 uses
(say) 64-bit words, then it'll get a new group.)
> Moreover, most
> questions about applications are application-oriented ("How do I do
> ... with this application?") rather than system-oriented ("How do I
> install ... on Unix?").
Really? Most problems I have with applications yeild to system-solutions.
If they don't, we get another application. :-<
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
\_.--._/
v Disclaimer: People have opinions, organisations have policy.
Wm E Davidsen Jr
| More simply, how about just creating...
|
| comp.unix.misc Unmoderated miscellaneous UNIX discussions.
| comp.unix.big-iron UNIX on Big Iron.
| comp.unix.apps Third-party applications (e.g., foxbase, lyrix, etc)
Horsefeathers! I think your complete proposal is a far better one,
don't back away from it! This seems to provide names and spaces for
everything, while avoiding creating groups for which there is no need.
I would like to see Peter's original proposal discussed and adopted.
It make a great deal of sense.
--
bill davidsen (davi...@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"Stupidity, like virtue, is its own reward" -me
Mark M Mehl
>> Perhaps we might consider starting a comp.unix.cpu.* hierarchy for
>> them:
>>comp.unix.cpu.i286
>>comp.unix.cpu.i386
>>comp.unix.cpu.m68k
pe...@ficc.uu.net (Peter da Silva) writes:
>Well, perhaps, but the CPU isn't the important part. It's the fact that
>it's running on a PC that uses that CPU:
>comp.unix.pc.i286
>comp.unix.pc.i386
Okay, but we "still" need to include something in the name so people
don't think "pc.i386" stands for a PC running Interactive Unix.
Would you prefer:
comp.unix.pc.intel386
comp.unix.pc.i386cpu
comp.unix.pc.cpu.i386
comp.unix.pc.i386based
comp.unix.pc.cpu.i386based
or is just good old
comp.unix.cpu.i386
clear enough?
I really think it's best to leave out the *.pc.* in the name because
it doesn't really clarify whether "i386" stands for Interactive Unix
systems on a PC or Intel 386-based systems in general. On the other
hand, adding the words "cpu", "intel", "-based" AND removing the "pc"
part does imply a certain emphasis on the system-level where the
processor (not the computer type) is what's important.
Moreover, if people realize it's an Intel 386-based system, they
already know the newsgroup is about PCs without the group name telling
them so.
Finally, the three groups mentioned below:
comp.unix.cpu.i286
comp.unix.cpu.i386
comp.unix.cpu.m68k
are really being separated by CPU-type, *not* whether or not they are
a PC, so CPU-type is the true distinction here, nothing more.
Sean Malloy
>Moreover, if people realize it's an Intel 386-based system, they
>already know the newsgroup is about PCs without the group name telling
>them so.
I wouldn't call the Sun 386i a 'PC', yet it uses the 80386 CPU. The
type of CPU used in a computer is not what makes it a 'PC'.
Sean Malloy | "The Crystal Wind is the
Navy Personnel Research & Development Center | Storm, and the Storm is Data,
San Diego, CA 92152-6800 | and the Data is Life."
mal...@nprdc.navy.mil | -- _Emerald Eyes_, D.K. Moran
Peter da Silva
> can afford to ignore either environment.
How about users?
> They're merging, anyway.
Are they merging, or is V.4 importing 4.4BSD, whereupon 4.5BSD will go on
its merry way again? (with or without wait5)
> And where would you put mixed bags like HP-UX?
comp.unix.misc, comp.unix.hpux, comp.unix.bsd, comp.unix.sys5, any and/or all
of the above... crossposting is your friend. mainly, if you don't know the
provenance of your question ".misc" is the best shot. But there's a whole
bunch of BSD stuff I personally couldn't care less about.
[deja-vu time... remember the debate about whether to keep comp.sys.amiga.tech]
How about comp.unix.admin for system administration issues. This is where
most of the BSD versus SYSV differences are (and will remain), possibly
splitting to comp.unix.admin.sys5 and comp.unix.admin.bsd.
> Further, we should *not* have an "apps" group. It would overlap with
> groups such as comp.databases and comp.text.desktop. The "misc" group
> will cover the proposed "apps" charter.
Probably. I suspect that another split for .misc will be in order 6 months
or so down the line, anyway.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.uu.net>
Peter da Silva
> comp.unix.pc.intel386
Yes.
> Moreover, if people realize it's an Intel 386-based system, they
> already know the newsgroup is about PCs without the group name telling
> them so.
You mean like the Sun 386i, Sequent's supermicro machines, the Unisys 6000
series (AKA ARIX somethingorother, I guess)?
> comp.unix.cpu.i286
> comp.unix.cpu.i386
> comp.unix.cpu.m68k
> are really being separated by CPU-type, *not* whether or not they are
> a PC, so CPU-type is the true distinction here, nothing more.
Perhaps, except that there *are* a lot of UNIX systems that use these
processors that aren't PCs. And despite my original ideas, there hasn't
been much non-PC discussion on comp.unix.i386. How about:
comp.unix.pc.i286 Discussions of UNIX on intel 286 processors.
comp.unix.pc.misc Discussions of UNIX on pc-class machines with
real processors (eg, 80386+, 680x0, etc).
Mark M Mehl
Some of the more popular choices included names like
comp.unix.cpu.i386 and comp.unix.pc.intel386.]
pe...@ficc.uu.net (Peter da Silva) writes:
>. . . there *are* a lot of UNIX systems that use these [Intel]
>processors that aren't PCs [Peter is referring to several 386-based
>engineering workstations mentioned earlier.]. . . . there hasn't
>been much non-PC discussion on comp.unix.i386.
This brings us to a fundamental question: Are 386-based workstation
users welcome to post in comp.unix.i386 or should we "insist" that
they post in comp.sys.workstations instead?
I would "prefer" if they could post in comp.unix.i386, in which
case the ".pc." should be left out of the group name. On the other
hand, if Usenet wants to exclude 386-workstation postings from
comp.unix.i386, then we better put the ".pc." in the name so
workstation postings don't show up there. What's it going to be?
Wm E Davidsen Jr
| This brings us to a fundamental question: Are 386-based workstation
| users welcome to post in comp.unix.i386 or should we "insist" that
| they post in comp.sys.workstations instead?
The bulk of the readers are running some vendors version of the AT&T
V.3.2/386 port. Anyone running SunOS would have more in common with the
workstation people. We share a common root o/s, and most people are
running something which has an AT bus. This allows us to share device
driver information, etc.
Chip Salzenberg
>> can afford to ignore either environment.
>
>How about users?
Point taken. A "sys5" group, then, really should have the "intel386"
group under it. We have discussed this. Its time has come:
comp.unix.bsd.admin BSD system administration
comp.unix.bsd.misc Miscellaneous BSD discussion
comp.unix.misc Miscellaneous discussion other than SysV/BSD
comp.unix.sys5.admin SysV system administration
comp.unix.sys5.286cpu SysV on the '286
comp.unix.sys5.386cpu SysV on the '386 (and '486)
comp.unix.sys5.misc Miscellaneous SysV discussion
comp.unix.xenix Xenix from SCO and others (just like now)
This scheme implies renaming, as follows:
comp.unix.questions -> comp.unix.misc
comp.unix.i386 -> comp.unix.sys5.386cpu
comp.unix.microport -> comp.unix.sys5.286cpu
Bouquets? Brickbats? And what should become of the currently
moderated group "comp.unix"?
Peter da Silva
Of course, but they would probably get better answers in comp.sys.sun,
comp.sys.workstations, etc. When the group was created, I explicitly
stated that sun 386i (and by extension, other workstations) would be
fine. The problem is, the group has *become* pretty much a System-V
based group. There probably aren't many BSD folks reading or posting,
and most workstations are BSD-derived.
Peter da Silva
> According to pe...@ficc.uu.net (Peter da Silva):
> >> However, we should *not* have "sys5" and "bsd" groups. No developer
> >> can afford to ignore either environment.
> >How about users?
> Point taken. A "sys5" group, then, really should have the "intel386"
> group under it. We have discussed this. Its time has come:
> comp.unix.bsd.admin BSD system administration
> comp.unix.bsd.misc Miscellaneous BSD discussion
> comp.unix.misc Miscellaneous discussion other than SysV/BSD
> comp.unix.sys5.admin SysV system administration
> comp.unix.sys5.286cpu SysV on the '286
> comp.unix.sys5.386cpu SysV on the '386 (and '486)
> comp.unix.sys5.misc Miscellaneous SysV discussion
> comp.unix.xenix Xenix from SCO and others (just like now)
Looks good to me, but I suspect that there will turn out to be a lot
of commonality between various PC-like System V systems. Right now, that
means System V/386, but AMIX (System V.4 on the Amiga 68030 boxes) is
coming up. I know, I brought that up as a problem before, but I suspect
that AMIX and System V/386 R4 people will have a lot in common.
How about:
comp.unix.sys5.286pc System V on the 80286 processor.
comp.unix.sys5.pc System V on "big" pcs.
> This scheme implies renaming, as follows:
> comp.unix.questions -> comp.unix.misc
> comp.unix.i386 -> comp.unix.sys5.386cpu
> comp.unix.microport -> comp.unix.sys5.286cpu
> Bouquets? Brickbats? And what should become of the currently
> moderated group "comp.unix"?
Leave it where it is, or make it comp.unix.digest.
Best keep things simple, and leave comp.unix and comp.unix.wizards
alone.
Anyone want to run a Chuqish simultaneous vote on this? (I'm elected?)
Fred Rump from home
>> This brings us to a fundamental question: Are 386-based workstation
>> users welcome to post in comp.unix.i386...?
>
>Of course, but they would probably get better answers in comp.sys.sun,
>comp.sys.workstations, etc. When the group was created, I explicitly
>stated that sun 386i (and by extension, other workstations) would be
>fine. The problem is, the group has *become* pretty much a System-V
>based group. There probably aren't many BSD folks reading or posting,
>and most workstations are BSD-derived.
But now we are selling, serving, teaching etc workstations on 398/486 boxes
using ODT from SCO. The interface is motive based and certainly different what
our friends from SUN and AT&T offer today and tomorrow. If SCO continuous it's
control of the market on the Intel line, there will certainly be lots of 486
workstations talking to a lot of 386 stations using Open Desktop.
That still leaves the original question unanswered.
fred rump
--
Fred Rump "Do not meddle in the affairs of cats, for they are subtle and will
26 Warren St. piss on your computer." domain: f...@icdi10.compu.com
Beverly, NJ. 08010 uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr
609-386-6846 "Freude... Alle Menschen werden Brueder..." - The Ode
Peter da Silva
> But now we are selling, serving, teaching etc workstations on 398/486 boxes
> using ODT from SCO. The interface is motive based and certainly different what
> our friends from SUN and AT&T offer today and tomorrow.
You mean "Motif"?
Look, whatever window manager you put on top of an X-windows GUI you put on top
of a System V/386 box (and I'm sure a lot of the Intel and AT&T folks will
use Motif rather than Open Look), it's still a System V/386 box running on
a high-end PC-class machine. The differences between it and someone running
TWM (my personal favorite) on X on an Intel System V system, or running Open
Look WM on top of X on an ISC system, are purely aesthetic. All these systems
use the same drivers, the same system administration tools, the same apps, and
so on.
> That still leaves the original question unanswered.
The answer to your question (what about System V based workstations) is "mu".
Or, "Of course SCO stuff fits in comp.unix.i386 under whatever name".
SCO is *not* the alien beast SCO's marketing arm dearly wishes to make it.
System V/386 is practically a commodity product, and SCO is selling the same
product as everyone else.
Now if you were talking about REALLY different 386 boxes, like the Unisys
6000s (AKA ARIX whatevers) or the Sequent stuff, then you'd have a case.
This is getting kind of marginal for news.groups. Yes, yes, it's still part
of the "unix group renaming" topic... but if we're going to start tossing
marketing claims around like last time just send Email.
Wm E Davidsen Jr
| SCO is *not* the alien beast SCO's marketing arm dearly wishes to make it.
| System V/386 is practically a commodity product, and SCO is selling the same
| product as everyone else.
Except for the system administration, security, and compilers this is
true. You can invest a lot of time on those exceptions.
Chip Salzenberg
>In article <262F12...@tct.uucp> ch...@tct.uucp (Chip Salzenberg) writes:
>> comp.unix.bsd.admin BSD system administration
>> comp.unix.bsd.misc Miscellaneous BSD discussion
>> comp.unix.misc Miscellaneous discussion other than SysV/BSD
>> comp.unix.sys5.admin SysV system administration
>> comp.unix.sys5.286cpu SysV on the '286
>> comp.unix.sys5.386cpu SysV on the '386 (and '486)
>> comp.unix.sys5.misc Miscellaneous SysV discussion
>> comp.unix.xenix Xenix from SCO and others (just like now)
>
>Looks good to me, but I suspect that there will turn out to be a lot
>of commonality between various PC-like System V systems.
Well, this is true. However, there are other SysV vendors (AT&T, for
example) that already have their own vendor-specific newsgroups.
Also, defining "PCs" is a task I do not want to attempt. :-)
Meanwhile, as another person has already pointed out, comp.unix.sys5
doesn't really fit in with the existing hardware-vendor-named scheme.
I therefore amend my proposal, as follows:
Create:
comp.unix.admin Unix system administration
comp.unix.misc Miscellaneous Unix discussion (was "questions")
comp.unix.286cpu Unix (not Xenix) on the '286 (was "microport")
comp.unix.386cpu Unix (not Xenix) on the '386 (was "i386")
Leave unchanged:
comp.unix Miscellaneous Unix discussion (Moderated)
comp.unix.wizards Esoteric discussions of obscure Unix issues
comp.unix.xenix Xenix from SCO and others
This proposal doesn't directly address the non-Intel (Amiga etc.)
people. I believe that the so-far-successful policy of creating
hardware-vendor-specific groups will be sufficient for them. For
example, the Amiga people can vote on comp.unix.amix if they want it.
I'm probably going to regret this, but unless anyone has objections,
I volunteer to run a Chuqish parallel vote on the reorganization.
I've never been involved in net.controversy, so I'll bring less
baggage along to confuse things.
NOTE: I am not going to run a vote on reeorganization as proposed
here. I'll hold off until we have a consensus on new/changed groups.
Tom Betz
|
|But now we are selling, serving, teaching etc workstations on 398/486 boxes
|using ODT from SCO. The interface is motive based and certainly different what
|our friends from SUN and AT&T offer today and tomorrow. If SCO continuous it's
|control of the market on the Intel line, there will certainly be lots of 486
|workstations talking to a lot of 386 stations using Open Desktop.
And not to be considered a one-platform company, SCO has just contracted with
DEC to port Sys V.3 UNIX (and Open Desktop, if I recall correctly) to their
workstations, so as to offer a huge ready-to-install base of UNIX software!
What's next, I wonder?
--
Thomas Betz, System Administrator | hombre!marob!upaya!root
Greyston Community Network / ZCNY | Greyston Community Network
(914) 375 - 1510 | 114 Woodworth Ave.
| Yonkers, NY 10701-2509
Peter da Silva
> Create:
> comp.unix.admin Unix system administration
> comp.unix.misc Miscellaneous Unix discussion (was "questions")
> comp.unix.286cpu Unix (not Xenix) on the '286 (was "microport")
> comp.unix.386cpu Unix (not Xenix) on the '386 (was "i386")
> Leave unchanged:
> comp.unix Miscellaneous Unix discussion (Moderated)
> comp.unix.wizards Esoteric discussions of obscure Unix issues
> comp.unix.xenix Xenix from SCO and others
Not bad. Not perfect, but it's certainly something I could live with. How
about a CFD? You can always do fine-tuning during the official discussion
period like Chuq did.
> I'm probably going to regret this, but unless anyone has objections,
> I volunteer to run a Chuqish parallel vote on the reorganization.
Thank you. I'm relieved.
Peter da Silva
The entry-level machine costs less than the down-payment on a small car.
That means that anyone who can afford a small car can afford to get into
the system without taking out a bank loan.
--
_--_|\ Peter da Silva <pe...@sugar.hackercorp.com>.
/ \
\_.--._/ I haven't lost my mind, it's backed up on tape somewhere!
v "Have you hugged your wolf today?" `-_-'
Tom Littauer
small networks. This is fine, since most UNIX environments are small right
now. Unfortunately this leaves no place to work through the issues of the
thousand-seat network, whether it be an Amdahl running UTS and ASCII tubes
or Xterms or an eclectic mix of smaller iron and workstations or ...
The point I'm trying to make is that many of you *WILL* have to face issues
of bigness sooner or later; providing a place for those of us doing so now
to discuss them will be valuable to you in the future.
While I'd love to see the group named comp.unix.amdahl or some such, I don't
think we should exclude the folks who're trying to run a corporation on a
network of SCO-based machines. The charter should be along the lines of:
To discuss very large networks and systems, and problems associated with
administering them (e.g. what's the backup strategy for .5 Terabytes?
what's the most cost-effective way to build a 5000 seat office automation
system? How do you keep the network from choking?)
Thanks for your attention
Peter da Silva
> In all of this comp.unix.* discussion, I see a focus on small machines and
> small networks. This is fine, since most UNIX environments are small right
My original suggestion had a "comp.unix.big-iron" for this purpose, but all
the feedback on that part of it was negative. I think it's a valid group,
and you make a good case for it (but could you perhaps come up with a better
name than comp.unix.huge... sounds like a memory model :->... or .big-iron...)
I think it should go into the proposal.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.uu.net>
Chip Salzenberg
>the feedback on that part of it was negative.
Well, we'd like to talk about large-scale installations, as in a
single large computer and/or lots of small ones.
What about "comp.unix.large-scale"?
Tom Littauer
>In article <ebrC02d...@amdahl.uts.amdahl.com> litt...@amdahl.uts.amdahl.com (Tom Littauer) writes:
>> In all of this comp.unix.* discussion, I see a focus on small machines and
>> small networks. This is fine, since most UNIX environments are small right
>> now. [but what about BIG systems?]
>
>My original suggestion had a "comp.unix.big-iron" for this purpose, but all
>the feedback on that part of it was negative. I think it's a valid group,
>and you make a good case for it (but could you perhaps come up with a better
>name than comp.unix.huge... sounds like a memory model :->... or .big-iron...)
>I think it should go into the proposal.
The only problem I have with "big-iron" is that is seems to be about machines
rather than systems. The issues to be addressed in this newsgroup are equally
germane to those who are trying to build multi-gigabyte databases on networks
of small machines. Since there's a lot of noise and flamage in the existing
comp.unix.* groups, it's difficult even to know if someone's trying to address
big system problems there.
If the collective net.wisdom insists on *.big-iron, well, OK. Big iron and
big iron vendors like us *DO* address big system problems...
Another possibility: comp.unix.corporate
I don't much care for it, but...
Peter da Silva
> big iron vendors like us *DO* address big system problems...
> Another possibility: comp.unix.corporate
Ich.
I think I prefer comp.unix.huge. I'd certainly vote for it under that name,
so don't twist it all to hell to please my weird whims.
--
_--_|\ `-_-' Peter da Silva. +1 713 274 5180. <pe...@ficc.uu.net>
/ \ 'U` Have you hugged your wolf today? <pe...@sugar.hackercorp.com>
\_.--._/ Disclaimer: commercial solicitation by email to this address
v is acceptable.
Mark M Mehl
>>the feedback . . . was negative.
>Well, we'd like to talk about large-scale installations, as in a
>single large computer and/or lots of small ones.
>What about "comp.unix.large-scale"?
All the names sound good to me, but if you want my favorite,
try comp.unix.large-sys or comp.unix.big-sys. I like
comp.unix.large-sys the best, but I can live with any of them.
Dave Mack
[wherein comp.unix.{huge,big-iron,corporate,et al} are discussed]
>
>I think I prefer comp.unix.huge. I'd certainly vote for it under that name,
>so don't twist it all to hell to please my weird whims.
I suppose comp.unix.mainframe would be too mundane? Or is the idea
to intentionally obscure the purpose of the group?
--
Dave Mack
Steve Lamont
>I suppose comp.unix.mainframe would be too mundane? Or is the idea
>to intentionally obscure the purpose of the group?
I'd prefer comp.unix.large-scale, which would both include mainframe UN*X and
large networks of UN*X boxes of perhaps smaller individual size.
spl (the p stands for
purpose? Who needs a
purpose?)
--
Steve Lamont, sciViGuy (919) 248-1120 EMail: s...@ncsc.org
NCSC (The other one), Box 12732, Research Triangle Park, NC 27709
Don't send in no bums. I want deals.
-John Steinbeck, _The Grapes of Wrath_
Peter da Silva
> >I think I prefer comp.unix.huge. I'd certainly vote for it under that name,
> >so don't twist it all to hell to please my weird whims.
> I suppose comp.unix.mainframe would be too mundane? Or is the idea
> to intentionally obscure the purpose of the group?
No, to keep it from being obscured. "Large UNIX system" isn't isomorphic with
"Mainframe UNIX system". How about distributed computing, for example?
Tom Littauer
>In article <1990May3.0...@alembic.acs.com> c...@alembic.acs.com (Dave Mack) writes:
>>I suppose comp.unix.mainframe would be too mundane? Or is the idea
>>to intentionally obscure the purpose of the group?
>
>I'd prefer comp.unix.large-scale, which would both include mainframe UN*X and
>large networks of UN*X boxes of perhaps smaller individual size.
This is where I'm settling, too. c.u.huge is just a little too ambiguous
and c.u.big-iron, .bigsys, and .large-sys faintly exclude distributed with
the subliminal association of system with computer. I'd settle for any of
them if pushed, though, 'cause I'm down to neat anatomical dissection of nits.
John R. MacMillan
|
|I think I prefer comp.unix.huge. I'd certainly vote for it under that name,
|so don't twist it all to hell to please my weird whims.
Seems vaguely misleading to me. I'd probably assume comp.unix.huge
was a SysV.4 group...
--
John R. MacMillan | For a long time I felt without style or grace
jo...@chance.UUCP | Wearing shoes with no socks in cold weather
...!utcsri!hcr!chance!john | -- Talking Heads