AIX question
Eric Scott Deese
Can anyone give any comments? Anything may be useful to me,
possibly even a comparison against other UNIX offerings for
the PS/2.
Thanks,
Eric Deese (osu-cis!liebert!esd)
Steve Dyer
>standard networking (telnet, ftp, rlogin), X-windows, NFS, UUCP, a number of
>compilers, etc.
NFS is not present in the first release of AIX PS/2. It's quite nice in
all other respects (as long as you remember to port "more" and alias
"tput clear" to "clear" :-))
Steve Dyer
dy...@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dy...@arktouros.mit.edu
Oleg Kiselev
>Does anyone have specific experience with AIX for the PS/2?
>Can anyone give any comments?
AIXPS/2 will be almost indistinguishable from any other BSD-like system. Job
control is there, so are all the familiar BSD utilities. On the PS/2 console
you also get access to multiple full-screen windows a la RT. You get all
standard networking (telnet, ftp, rlogin), X-windows, NFS, UUCP, a number of
compilers, etc.
>Anything may be useful to me,
>possibly even a comparison against other UNIX offerings for
>the PS/2.
There are going to be comparative price/performance reviews of AIX vs other
386 UNIX ports in the next month or two in UNIX trade rags. Wait for
official bull-dada.
--
"No regrets, no apologies." -- Ronald Reagan
Oleg Kiselev ARPA: lcc....@seas.ucla.edu, ol...@gryphon.COM
(213)337-5230 UUCP:...!ucla-cs!lcc!oleg
Oleg Kiselev
>NFS is not present in the first release of AIX PS/2.
It's coming, though. We have it running on Gen 2.
>It's quite nice in
>all other respects (as long as you remember to port "more" and alias
>"tput clear" to "clear" :-))
You mean those fools at IBM did not package "more" and "clear"? I bet they
just did not have a test suite to test that stuff because RT did not have it
-- so they just dropped the functionality so that PS/2 looks like RT and they
do not have to think about the way to test "clear". Can you say "Duh..."?
(Yes, we have both "more" and "clear" in developement environment).
>
>Steve Dyer
>dy...@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
>dy...@arktouros.mit.edu
rja
The real problem with AIX for the PS/2 series is that it is not
_binary_ compatible with UNIX V/386 release 3.2 as Xenix is. Lotus,
WordPerfect, et. al. are committed to developing for V/386 3.2
because it lets the same binary run regardless of whether you have
SCO, Interactive, Microport, BellTech, Everex, or AT&T's V/386.
I see no such commitment to develop binary versions for AIX/PS.
AIX is generally a port of System V.2 and so it lacks STREAMS and
other goodies, but as V.2 ports go, it should be pretty good and
IBM has tweaked it some and will provide support.
Don Steiny
> AIXPS/2 will be almost indistinguishable from any other BSD-like system. Job
> control is there, so are all the familiar BSD utilities. On the PS/2 console
> you also get access to multiple full-screen windows a la RT. You get all
> standard networking (telnet, ftp, rlogin), X-windows, NFS, UUCP, a number of
> compilers, etc.
Does it use the 4.2BSD file system? Does it have long file names?
What about drivers? By System Vr3 it has gotten pretty easy
to incorporate a new driver into a system, thus you can get all kinds
of nifty add ons. Does AIX provide the .o files for the kernel so
that we can add our own drivers?
Don Steiny
Oleg Kiselev
>> AIXPS/2 will be almost indistinguishable from any other BSD-like system. Job
Filesystem is somewhat different:
There is an additional type of object -- a hidden directory, which contains
multiple load modules for different CPU types (and different other selection
criteria, see "xvers" [or is it now "uvers"?] command documentation in AIX
manuals for gory details).
Small objects (directories or files under 384 bytes in length) get "sucked"
into the inode and take up no file blocks (i.e. they are 0 size for "du").
There is (in Gen2 release) a concept of files and directories existing on a
replicated filesystem on a site, but not being stored there -- that makes
certain operations on the files very, ahem!, inetersting if you want to
examine the filesystem on the raw device.
There is a concept of "commit counts" for inodes, which provide each inode in
the file system (as well as telling the superblock) with a unique sequencing
number which allows TCF/AIX to synchronize replicated filesystem updates even
when a filesystem was not mounted (say, site was down) when update to the
primary copy was made...
There is a possibility of a device node belonging to a different site and
referring to a remote device -- the only way to tell is to ask for "owner"
site on ls (I can't recall the option... "ls -lZ" or "ls -lz"?)
But yes, long name directories are there, as well as opendir(), readdir() and
friends. For those concerned with security -- mkdir() is a system call.
> What about drivers? Does AIX provide the .o files for the kernel so
>that we can add our own drivers?
I have not used the "delivered" system, so I don't know. There is a "config"
program that allows user to re-link the kernel, but I am not sure if that
is a part of the base release or if it's one of the add-on packages.
Frank J. Edwards
>
> Does it use the 4.2BSD file system? Does it have long file names?
I don't know. Yes (would seem to indicate at least a BSD directory
structure, if nothing else).
> What about drivers? By System Vr3 it has gotten pretty easy
> to incorporate a new driver into a system, thus you can get all kinds
> of nifty add ons. Does AIX provide the .o files for the kernel so
> that we can add our own drivers?
Yes, there is a configurable kernel. I have not investigated this
thoroughly, though, and do not know to what extent. But there is
a directory which contains the kernel's .o files (stored in libraries
actually).
> Don Steiny
Frank "Crash" Edwards
...!uunet!pdn!jc3b21!crash
Disclaimer: I do not work for IBM. I do not own a PS/2. I do not
have AIX running on a PS/2 within 500 miles of where I work. But I
do teach "Installation and Implementation" courses for AIX/PS2 and
have installed/used quite a few since October of last year. However,
things change as code develops, soooo... if I'm wrong about this:
too bad! (I estimate a 94.7% accuracy rate.)
Steve Dyer
No.
>Does it have long file names?
Yes.
> What about drivers? By System Vr3 it has gotten pretty easy
>to incorporate a new driver into a system, thus you can get all kinds
>of nifty add ons. Does AIX provide the .o files for the kernel so
>that we can add our own drivers?
You get a set of archive libraries containing the OS objects. I assume
you should be able to add a driver, but I'll have to check whether they
provide the source to conf.c or provide some other way to get your driver
shoved into the device switch table(s).
--
Frank I. Reiter
>
>AIX is generally a port of System V.2 and so it lacks STREAMS and
>other goodies, but as V.2 ports go, it should be pretty good and
>IBM has tweaked it some and will provide support.
I've seen IBM *nix support:
A couple of years ago I was using IBM Xenix rather than SCO. I needed to
replace the hard drive and so I called IBM tech support to ask how to backup
and restore a root partition. The fellow umed and ered for a while, then
asked "Well, have you tried COPY *.* ?" This was the man in charge of Xenix
supprt at the time.
--
_____________________________________________________________________________
Frank I. Reiter UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank
Reiter Software Inc. fr...@rsoft.bc.ca, a...@mindlink.UUCP
Langley, British Columbia BBS: Mind Link @ (604)533-2312, login as Guest
Oleg Kiselev
>You get a set of archive libraries containing the OS objects. I assume
>you should be able to add a driver, but I'll have to check whether they
>provide the source to conf.c or provide some other way to get your driver
>shoved into the device switch table(s).
Ugh... I think it uses /etc/system to do configuration. You have to use
"devices" program to add information to /etc/system and run config to rebuild
the kernel. It is supposed to be much like RT in that respect.
Oleg Kiselev
In article <19...@edison.GE.COM> r...@edison.GE.COM (rja) writes:
>The real problem with AIX for the PS/2 series is that it is not
>_binary_ compatible with UNIX V/386 release 3.2 as Xenix is.
To be binary compatible with UNIX V/386 would have requiered sVr3 licence
(which AT&T had written up in a very silly way, something they are apparently
changing for sVr4) and would have prevented AIX PS/2 from being able to use a
significantly different file system, different mechanisms for signal
handling, etc.
>Lotus, WordPerfect, et. al. are committed to developing for V/386 3.2
>because it lets the same binary run regardless of whether you have
>SCO, Interactive, Microport, BellTech, Everex, or AT&T's V/386.
>I see no such commitment to develop binary versions for AIX/PS.
Considering the market share IBM intends to capture and their tight
relationship with the software publishers, I strongly suspect all that
software will soon become readily available. Besides, can any of the afore
mentioned UNIX versions boast 4.3 code compatibility and POSIX compliance?
>AIX is generally a port of System V.2 and so it lacks STREAMS and
>other goodies,
It has sockets, if that's any consolation.
>but as V.2 ports go, it should be pretty good and
>IBM has tweaked it some and will provide support.
IBM tweaked nothing. LCC did all the work under contract to IBM. AIX,
internally, is substantially different from both 4.3 and sVr2 kernels, but it
combines features of both and allows easy porting of applications designed
for either version of UNIX. In Gen2 release (TCF), a wealth of BSD utilities
will probably come standard with the base system (yes, that include 4.3 BSD
version of "more(1)" with back-paging and tset :-).
Mike McNally
>AHEM! There seems to be some misunderstanding here:
>
>In article <19...@edison.GE.COM> r...@edison.GE.COM (rja) writes:
>>The real problem with AIX for the PS/2 series is that it is not
>>_binary_ compatible with UNIX V/386 release 3.2 as Xenix is.
>
>To be binary compatible with UNIX V/386 would have requiered sVr3 licence
Why? My company sells an OS that runs Sys V/386 binaries just fine, and we
don't have a source license to anything.
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.
Oleg Kiselev
>>To be binary compatible with UNIX V/386 would have requiered sVr3 licence
>don't have a source license to anything.
My understanding is that IBM was not willing to mess with possible copyright
problems and opted not to pay for the ndependent developement of functionality.
I don't know what the legal ramifications of creating 100% compatible clones
of a copyrighted product may be. If the examples of Lotus vs. clones,
Intel vs. NEC and Apple vs. world are any kind of a guideline, it seems that
it's easier not to mess with the issue and tread carefully.
Dick Dunn
> >_binary_ compatible with UNIX V/386 release 3.2 as Xenix is.
>
> To be binary compatible with UNIX V/386 would have requiered sVr3 licence
Why? Is there some patent or license that says you can't use SVR3 object
format unless you're licensed? I'm willing to be convinced, but I'm
skeptical. From the rumors I've heard, I might believe that IBM would have
been unwilling to sign a license under the V.3 terms, but how does that
imply that they couldn't have been compatible with the object format?
> ...and would have prevented AIX PS/2 from being able to use a
> significantly different file system,...
in what way? Consider that Interactive uses a file system which is very
different in its allocation of blocks to a file as the file grows (which is
most of what matters for performance), yet it is S V.3 licensed. In fact,
it's media-compatible!
> Considering the market share IBM intends to capture and their tight
> relationship with the software publishers, I strongly suspect all that
> software will soon become readily available...
This is an interesting speculation, but that's all it is. The difference
between "intends to capture" and "holds" is a night-and-day difference! I
don't wish to belittle IBM's ability to go after a market; I just want to
point out that (even for IBM) the difference between what you want and what
you have is usually nonzero and frequently significant.
--
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
...Relax...don't worry...have a homebrew.
Oleg Kiselev
>From the rumors I've heard, I might believe that IBM would have
>been unwilling to sign a license under the V.3 terms, but how does that
>imply that they couldn't have been compatible with the object format?
I am not sure of the exact reasons. It COULD have been a time and effort
issue ( Given the incredible amount of QA IBM does on the software, it
would make a lot of sense to pass on what is deemed as inessential
functionality.) I am not sure at this point what I can and can not say in
public -- confidentiality is a big thing with IBM and I am not in the mood
to look for another job :-).
>I just want to
>point out that (even for IBM) the difference between what you want and what
>you have is usually nonzero and frequently significant.
Consider the number of vendors IBM got to port things for RT -- and RT was a
dog running a brain-damaged UNIX (sorry, people from Interactive, but even if
you had delivered a good UNIX to IBM, they had mutilated it and dressed it up
funny) -- and all that software is easily portable to AIX PS/2 (IBM made sure
of that). Unless IBM does the same thing with AIX PS/2 that they did with
PC/IX, VM/IX and other UNIX ports they commissioned and slaughtered, which
does not seem to be the case here, AIX PS/2 may become a dominant force in
micro UNIX market (it certainly is a great system). And if AIX becomes the
basis of OSF, it will become the dominant force in UNIX market accross the
entire spectrum of machines...
Steve Dyer
>PC/IX, VM/IX and other UNIX ports they commissioned and slaughtered, which
>does not seem to be the case here, AIX PS/2 may become a dominant force in
>micro UNIX market (it certainly is a great system).
Oleg, your equivocations are making me dizzy! But seriously, there's no
reason to expect that IBM will break away from a uniformly poor record here.
Hope against hope, perhaps...
AIX PS/2 doesn't have a chance of becoming dominant in the micro UNIX
market until it runs on machines other than the IBM PS/2s. Unless you
believe that the PS/2 will become a dominant force in the micro UNIX
market. Right. Have you considered writing for the trade rags? :-)
SCO UNIX, AT&T Sys V.3/386, Microport UNIX/386, and ISC 386/ix provide
a binary-compatible ABI across just about any 386-style clone including
PS/2s. Locus (or even hack, gasp, IBM) has quite an opportunity here,
if it finds some way to sell its AIX port on generic 386 clones. Even
better it should spend the time and money to provide V.3/386 ABI compatibility
for 95% of all 386 programs. It's only the low-level code which depends on
the PS/2 interrupt structure and the particular PS/2 device adapters.
Goodness knows, Locus (the OS) has run on all sorts of machines.
>And if AIX becomes the
>basis of OSF, it will become the dominant force in UNIX market accross the
>entire spectrum of machines...
Well, the so-called OSF-1 *isn't* the Locus AIX, unless I'm mistaken.
The confusion is that IBM and its minions use the word "AIX" for apples
(RT) and oranges (PS/2). OK, they have (mostly) the same source application
programming interface, but you could say the same about SCO UNIX and
ISC's 386/ix. They have radically different heritages and are being
corralled, reluctantly, under the same rubric. The name comes first,
the family resemblance later. Will TCF and other Locus-isms be part of
the OSF-1 OS specification?
--
T.H. White
> AIX PS/2 doesn't have a chance of becoming dominant in the micro UNIX
> market until it runs on machines other than the IBM PS/2s.
Right! You're just pissed beause IBM's "great" AIX system won't run on
your wimpy 386 box! If you would have invested in a PS/2 (not a
considerable amount more than a "good" 386 clone) and bought AIX for it,
you would now realize that AIX leaves these other 386 UNIX's in the
dust! There is no doubt about it, IBM's AIX will be the new standard.
Yes, they could easily port AIX to a non micro-channel 386 machine, but
then it wouldn't be IBM now would it?
> SCO UNIX, AT&T Sys V.3/386, Microport UNIX/386, and ISC 386/ix provide
> a binary-compatible ABI across just about any 386-style clone including
> PS/2s.
So, everyone else in the near future will want AIX compatible code.
> >And if AIX becomes the
> >basis of OSF, it will become the dominant force in UNIX market accross the
> >entire spectrum of machines...
If AIX becomes the basis of OSF? See'in as how IBM has the major
interest in OSF, don't you think maybe AIX will be the basis for it?
I'm sure it will be. Yes I think you are right, IBM will become the
dominant force in the UNIX market especially once they get their
"real" AIX/370 out the door.
THW
PS: "No. I do not work for IBM!"
T.H. White
> In article <15...@gryphon.COM> ol...@gryphon.COM (Oleg Kiselev) writes:
> >AIX PS/2 may become a dominant force in micro UNIX market
> >(it certainly is a great system).
>
> on hardware that is not based on the PS/2 bus. AIX has to be able to
> sell both the hardware and the software as a solution. The other
> UNIXes are more open in that they do not require any particular
> 386 hardware platform.
Yes, but the PS/2 hardware platform is far superior to the standard AT
bus 386 system. If the price on the PS/2 systems would only come down to
that of an identical 386 AT bus system, I think you would see IBM's
AIX and PS/2 machines be in very high demand.
THW
Rick Richardson
>AIX PS/2 may become a dominant force in micro UNIX market
>(it certainly is a great system).
I think you'll find that the 386 UNIX market is by and large running
on hardware that is not based on the PS/2 bus. AIX has to be able to
sell both the hardware and the software as a solution. The other
UNIXes are more open in that they do not require any particular
386 hardware platform.
--
Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2
PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2
uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms.
jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
Dick Dunn
> Yes, but the PS/2 hardware platform is far superior to the standard AT
> bus 386 system. If the price on the PS/2 systems would only come down to
> that of an identical 386 AT bus system, I think you would see IBM's
> AIX and PS/2 machines be in very high demand.
I can't agree that cost is really a problem. You and I may think so, but
the folks who have traditionally bought IBM equipment have always done so
in spite of a price-performance difference against IBM. They buy because
they want that label on the box, and all it implies to them. Granted,
cost may have made PS/2 sales slightly lower than they would have been
with what you might think would be "good" prices, but it can't explain
anywhere near the full difference between what PS/2 sales are and what they
"should" have been.
There are a few other fairly obvious factors to which one might attribute
the slow sales.
Oleg Kiselev
>market until it runs on machines other than the IBM PS/2s.
I am gambling on a possibility (admittedly uncertain) that AIX-370 will usher
in the PS/2 and AIX-PS/2 sales. After all, while the other 386 UNIX ports
are binary compatible among themselves, they are incapable of supporting TCF
and *THAT* may be the ultimate idea. After all, to someone who buys a vector
processing 3090 to do number crunching, provide hundreds om Meg of RAM and
support terabytes (sp?) of disk space, 20 or so PS/2's to serve as async
access and character I/O processes (like editors, etc) support machines are
a drop in a bucket...
>SCO UNIX, AT&T Sys V.3/386, Microport UNIX/386, and ISC 386/ix provide
>a binary-compatible ABI across just about any 386-style clone including PS/2s.
Ahem... What about Sun? Do they have a binary compatibility with the above
on their 386 machine? Or any of their other machines?
>Locus (or even hack, gasp, IBM) has quite an opportunity here,
>if it finds some way to sell its AIX port on generic 386 clones. Even
>better it should spend the time and money to provide V.3/386 ABI compatibility
>for 95% of all 386 programs.
Well, yes. But we are not IBM and we do not write IBM business strategies or
influence significantly their planning. We are like any contractor -- hired
to provide our expertise and licence our technology to them (what they called
TCF).
>Goodness knows, Locus (the OS) has run on all sorts of machines.
Well, yes, it did. (I would rather drop THIS line of discussion as well -- I
am not sure, again, how confidential is my information).
>Well, the so-called OSF-1 *isn't* the Locus AIX, unless I'm mistaken.
>The confusion is that IBM and its minions use the word "AIX" for apples
>(RT) and oranges (PS/2).
Oh, no... NOBODY is stupid enough to accept RT's AIX as a standard for
ANYTHING. Now, Version 3 (or is that Release 3?), which is a complete
rewrite without (from what I understand) the brain-damage of VRM and with
completely re-written state-of-the-art kernel, is a different story.
OSF is likely be POSIX compliant and inherit the better features of AIX (of
which there is a number).
>Will TCF and other Locus-isms be part of the OSF-1 OS specification?
LCC's top management would probably like that. And IBM would get something
unique to hold as a trump card against other OSF members.
Bruce A. McIntyre
real market prices of some of the volume machines out there, you will find
that a Compaq386/25 is demanding a considerably higher street price than
an IBM Model80, Model70. The users don't find the "premium" for MC all
that great. When 10 CPU systems become common, maybe. But then AIX don't
support multi-processing yet anyway, right? If you need multi-processing
RIGHT NOW on a 386 based machine for a price, then use Zenith (Corollary),
which oddly enough runs a version of (gasp) XENIX, or if you need big time
multi-processor machines, how abount Sequent. I wonder if THEY use
micro-channel??
bruce
--
=========================================================================
Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895
143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915
{wells|lgnp1}!mdi386!bruce bruce@wells tbit+
Unix, Xenix, Netware and PC-DOS Applications development.
Specializing in Database Applications since 1980.
rja
> AHEM! There seems to be some misunderstanding here:
In article <19...@edison.GE.COM> r...@edison.GE.COM (rja) writes:
% _binary_ compatible with UNIX V/386 release 3.2 as Xenix is.
> To be binary compatible with UNIX V/386 would have requiered sVr3 licence
> (which AT&T had written up in a very silly way, something they are apparently
> changing for sVr4) and would have prevented AIX PS/2 from being able to use a
> significantly different file system, different mechanisms for signal
> handling, etc.
No misunderstanding. I want System V.3, and I want binary compatibility
with Xenix and COFF, and I want STREAMS (see below). As a user/developer
I don't care what IBM's opinion of AT&T's license is; I want to use
the de facto standard which for 80286 and 80386 chips is clearly the
AT&T UNIX System V/386 product (whether packaged by BellTech, Interactive,
Microport, Everex, Dell, or AT&T matters to me not at all).
% Lotus, WordPerfect, et. al. are committed to developing for V/386 3.2
% because it lets the same binary run regardless of whether you have
% SCO, Interactive, Microport, BellTech, Everex, or AT&T's V/386.
% I see no such commitment to develop binary versions for AIX/PS.
> Considering the market share IBM intends to capture and their tight
> relationship with the software publishers, I strongly suspect all that
> software will soon become readily available. Besides, can any of the afore
> mentioned UNIX versions boast 4.3 code compatibility and POSIX compliance?
I see WordPerfect software available NOW. No major publisher has yet
announced support for AIX. All have for UNIX System V/386.
UNIX System V/386 release 4 is due out this year and will have most all
of the 4.3 BSD built-in. System V.3.2U is already POSIX compliant.
% AIX is generally a port of System V.2 and so it lacks STREAMS and
% other goodies,
> It has sockets, if that's any consolation.
No consolation. I can build a sockets interface on top of STREAMS and TLI,
but I cannot build STREAMS on top of sockets. In fact AT&T will
reportedly offer a STREAMS module that implements a sockets interface
for backwards compatibility with 4BSD when UNIX System V.4 arrives.
UNIX is a registered trademark of AT&T Bell Laboratories.
Guy Harris
>>a binary-compatible ABI across just about any 386-style clone including PS/2s.
>
>Ahem... What about Sun? Do they have a binary compatibility with the above
>on their 386 machine? Or any of their other machines?
Well, he *did* say "386-style clone"; the Sun386i ain't any sort of
PClone. However, no, at present, it has no binary compatibility with
S5R3 on the 386; I would expect it to run an S5R4-based system ("SunOS
5.0", probably) in the future, and I'd expect that to be able to run
S5R3 binaries.
Greg Onufer
> Ahem... What about Sun? Do they have a binary compatibility with the above
> on their 386 machine? Or any of their other machines?
Sun is gearing up to use AT&T/Intel/whoever's 386 ABI. The Roadrunner
_already_ uses COFF object files and ELF, from what I hear, is on it's way,
and that's the first step to the AT&T SVR4 386 ABI.
Disclaimer: this is hearsay from Unix World and several e-mail messages
I have received.
Cheers, Greg.
Oleg Kiselev
>However, no, at present, it [Sun] has no binary compatibility with
>S5R3 on the 386; I would expect it to run an S5R4-based system ("SunOS
>5.0", probably) in the future, and I'd expect that to be able to run
>S5R3 binaries.
Well, AT PRESENT AIX does not provide binary compatibility with sVr3. I am
sure that if IBM sees undeniable commercial benefits from that feature,
future versions of AIX may gain the capability. Basically, I feel that the
feature is not there not because it was impossible to add it, but because it
was not considered essential or important at this point by IBM.
On the other hand, the ability to run DOS processes in virtual 8086 machines
is there and works just fine (tetris and Microsoft Flight Simulator run just
fine).
John L. Grzesiak
> > that of an identical 386 AT bus system, I think you would see IBM's
> > AIX and PS/2 machines be in very high demand.
>
> the slow sales.
> --
difference between the two architectures. And , yes , the micro channel is
superior. But with no second sourcing options and the ever present IBM
marketing perogatives, the micro channel is simply too frightening a
proposal to someone who wants support (And doesn't like dealing with IBM's
attitude on end user support). I expect to see the new E.I.S.A. buss to
take off though (Functionally it is the equal of micro-channel), and rumor
has it that Dell's first entry for this buss is ready! In conclusion I can
say this about IBM - When they try to lead the industry - DISASTER.... when
the follow - WONDERFULL...
The opinions are my own... -- John Grzesiak --
Evan Leibovitch
>feature is not there not because it was impossible to add it, but because it
>was not considered essential or important at this point by IBM.
To me, this speaks volumes if it is indeed IBM's attitude.
As recently as May 19, as a keynote speaker at the Canadian Unix Show,
Nicholas Donofrio (IBM VP and Pres of the Advanced Workstation Division)
was extolling how IBM is *driving* the move to standards conforimity,
compatability, and open systems.
That AIX is not shrinkwrap compatible with 386 SysV flies in the face of
this. That such compatability is technically possible but not considered
essential from the start, is even worse.
IBM is forcing software developers to do two different software releases of
each product, if they want to cover the entire Unix-on-386 marketplace.
Further, it comes at a time when we thought that was all cleared up after
the Xenix/Unix merger in 3.2.
The need for both AIX and SysVr3.2 versions of software is a disincentive
for software developers to do any Unix ports, when other environments like
OS/2 or VMS offer a single way to do things.
To this end, any technical excellence of AIX is offset by the FUD (and
long-term industry harm) it creates. Just when you though everyone was
getting together on standards, IBM re-invents the wheel. Or at least, a
major spoke.
>I am sure that if IBM sees undeniable commercial benefits from
>[binary compatability with SysVr3.2], future versions of AIX may gain
>the capability.
In other words, the company will go along with everyone else if and
only if nobody buys into its (essentially proprietary) method of
distributing binaries.
IBM Open Systems. Still an oxymoron, even in the commodity 386 world. Sigh.
--
Evan Leibovitch, SA, Telly Online, located in beautiful Brampton, Ontario
ev...@telly.on.ca / {uunet!attcan,utzoo}!telly!evan / (416) 452-0504
Computer salesman's credo: There's an end-user born every minute
Oleg Kiselev
>>Basically, I feel that the
>>feature is not there not because it was impossible to add it, but because it
>>was not considered essential or important at this point by IBM.
>To me, this speaks volumes if it is indeed IBM's attitude.
Do not judge IBM's attitude by my "feelings" -- I am not employed by IBM, nor
have I been appointed their speaker. I am just expressing my opinion based
on the facts known to me. If you really care about what IBM's attitude is,
you should probably direct your questions to them.
>As recently as May 19, as a keynote speaker at the Canadian Unix Show,
>Nicholas Donofrio (IBM VP and Pres of the Advanced Workstation Division)
>was extolling how IBM is *driving* the move to standards conforimity,
>compatability, and open systems.
>That AIX is not shrinkwrap compatible with 386 SysV flies in the face of
>this. That such compatability is technically possible but not considered
>essential from the start, is even worse.
"Open system" is not synonymous with "binary compatibility". IBM seems to be
trying to achieve SOFTWARE compatibility between various hardware platforms.
I realize that this is an "i386" group and you are most interested in that
processor, but AIX lives on not only 386, but on 370 as well (and, without
LCC's enhancements, on RT).
You are ignoring the obvious -- AIX is a cross-platform system.
>IBM is forcing software developers to do two different software releases of
>each product, if they want to cover the entire Unix-on-386 marketplace.
(What about Sun? To run on Sun, one must do yet another port!)
As long as software does not use streams and a few other sVr3-specific
facilities, it should easily port to AIX. It does add to QA and packaging,
but I am not sure how much.
>Further, it comes at a time when we thought that was all cleared up after
>the Xenix/Unix merger in 3.2.
Consider AIX in the same league as you consider any other UNIX which runs on
multiple hardware platforms -- it's a different class of problems and a
different set of goals.
>The need for both AIX and SysVr3.2 versions of software is a disincentive
>for software developers to do any Unix ports, when other environments like
>OS/2 or VMS offer a single way to do things.
OS/2 and VMS do not run on 370 or RT. Your statement about "disincentive" is
abit of an over-generalization, especially when it comes to AIX -- porting
system V and BSD applications to AIX is very easy and would hardly be a
deterrent to software development.
>In other words, the company will go along with everyone else if and
>only if nobody buys into its (essentially proprietary) method of
>distributing binaries.
I do not know that. I do know that binary compatibility has not been an
issue with UNIX before mass-proliferation of 386 boxes and I do know that an
ability to run your software on a diverse class of machines seems quite
important. IBM seems to be offering a UNIX which runs on machines from 386
to the largest 370 and XA (3090, for example). I think we should be looking
beyound binaries.
daniel mocsny
[ about how binary standards don't help large users wanting to upgrade to
larger machines ]
I think the issue of binary standards is not quite as important for
the market segment consisting of large systems users as it is for the
general desktop market. In 1988 something like 200,000 UN|X systems
shipped, compared to 10,000,000 MS-DOS systems. MS-DOS has not
succeeded on any sort of technical merit. It has succeeded, and is now
quite unstoppable for the next several years, because it represents
the largest existing homogeneous binary standard. Most MS-DOS systems
ship through low-margin channels and wind up in the hands of people
who don't have either the time or the inclination to spend their days
hacking Makefiles and watching compiles break.
Neither the users, nor the retailers and VARs that sell these
machines, can possibly tolerate more than a very limited number of
binary standards. If you walk into a retail software store you will
see very limited shelf space. None of these low-margin operations
could possibly afford to stock fifty versions of one title. And why
should users have to be bothered with the making sure they have the
right version of a title? The industry should serve the customer,
rather than the other way around. Ideally that means not forcing the
user to think about things that have nothing to do with the user's
application. The more time the user has to spend before getting to
a solution, the fewer users there will be.
The retail channel is already up to its ears trying to keep up with
the proliferation of technology. Ditto for corporate micro support
personnel. Ditto for users. Seemingly minor incompatibilities give
everyone a few extra details to think about every time they want to do
anything involving more than one machine. Taken together, these
little wastages can make the difference between an application being
feasible now vs. waiting for a few more years. This adds up to lost
markets. Not every potential computer application is profitable enough
to force users to put up with X amount of entropy in the computer
industry. The less entropy the computer industry can present to the
user, the bigger and richer the industry will be. The vast installed
base of MS-DOS machines can support many more marginally profitable
applications than can the smaller installed base of any of the UN|X
variants. UN|X cannot compete on technical merits alone; it must also
attain similar economies of scale.
Software (quasi-)compatibility is fine for large organizations that
can afford to hire trained specialists to deal with the overhead of
horizontal fragmentation. But if we are to advance beyond the
mainframe model of the 1960's, and make the computer into some sort of
generally useful device, the industry as a whole must strive to
present the most uniform environment that it can to the user. At a
bare minimum, this means having no more than one binary standard per
CPU family, and solid software compatibility between platforms.
Dan Mocsny
dmo...@uceng.uc.edu
Oleg Kiselev
>No misunderstanding. I want System V.3, and I want binary compatibility
>with Xenix and COFF, and I want STREAMS (see below).
Sorry, currently there is no STREAMS in AIX. Neither in any 4.3 BSD system
widely available on the market.
>I don't care what IBM's opinion of AT&T's license is; I want to use
>the de facto standard which for 80286 and 80386 chips is clearly the
>AT&T UNIX System V/386 product
It's not an opinion that matters, it's the unfortunately unfavourable to
UNIX porting/support house legal language of sVr3 source license. I
understand that sVr4 license was written diffrently. IBM may yet decide to
provide the binary compatibility you are looking for. (By the way, how could
sV/386 be standard for 286 chips?)
>I see WordPerfect software available NOW. No major publisher has yet
>announced support for AIX. All have for UNIX System V/386.
How long has sV/386 been out? Give it time. AIX comes with a large number
of applications marketed by IBM. I am sure OEM's will soon add to the
already rich selection.
>UNIX System V/386 release 4 is due out this year and will have most all
>of the 4.3 BSD built-in. System V.3.2U is already POSIX compliant.
AIX is very much (99%?) BSD 4.3 compatible already. And, unlike the "soon to
be released" promises, AIX is extensively tested and debugged. AIX PS/2 is a
particular solution. If that particular solution does not fit your problem,
then you can either suggest to IBM what enhancements would make AIX a right
solution to your problem, or choose another solution. I would hope that you
choose the former, but even if you do not, your hostility and vehemence are
hardly justified.
Rick Richardson
>
>I do not know that. I do know that binary compatibility has not been an
>issue with UNIX before mass-proliferation of 386 boxes and I do know that an
>ability to run your software on a diverse class of machines seems quite
>important.
This is false. It was recognized in the UNIX community, long before
386 boxes proliferated, that binary compatibility was needed in order
to spur growth of UNIX applications. It is easy to say that you have
source code compatibility, and UNIX has had that (more or less) for a
long time. But without binary compatibility, an application developer
needs to test and support each and every machine/os combination. You
can't just assume that because you compiled the source with no errors
that the application will run on some foreign UNIX. It has to be
tested, as if it was the first time it was compiled, since you can't
be 100% sure that the compiler or some other subtlety hasn't broken
something. With binary compatibility, once you are convinced that
two systems are, in fact, binary compatibile you don't need to waste
time doing a complete from ground up system test on each hardware
platform for each new release of the application.
Not to mention that you save on documentation, packaging, advertising,
and all the other stuff that most programmers aren't aware of.
To think that only source compatibility is acceptable for the largest
market segment is a step in the wrong direction, and certainly not
what most people know is needed. There are many companies, selling
hardware and operating systems, whose applications developers would
have divorced them had they not maintained binary compatibility across
hardware and OS releases. You may even have been paid by one.
karl lehenbauer
> your wimpy 386 box! If you would have invested in a PS/2 (not a
> considerable amount more than a "good" 386 clone) and bought AIX for it,
> you would now realize that AIX leaves these other 386 UNIX's in the
> dust!
This is a joke, right? First of all, I'm not sure what you define as a "good"
clone, I guess a 33 MHz Compaq or something, but I bought a Mylex 4 MB 16 MHz
motherboard for $1000 and a memory trade-in (from my 286) and it's been working
great, running Unix, for over a year. Not one problem... a "good" machine.
I got to keep my disk controller, disk drives, display board, monitor, power
supply, chassis -- the works. Ahh, compatibility...I saved thousands and,
if my machine isn't quite as fast as one that costs $8000, so what? (It
still cranks 5000 dhrystones with AT&T's cc)
A PS/2 Model 55 SX is to cost $4295 with a 60 MB hard disk -- and that's not
even a 386!
Should those of us already running Unix really have bought PS/2's and waited
'til now for AIX, given IBM's miserable Unix/Xenix track record so far?
> There is no doubt about it, IBM's AIX will be the new standard.
That has yet to be shown. I would say "IBM's AIX will be *a* new standard."
> Yes, they could easily port AIX to a non micro-channel 386 machine, but
> then it wouldn't be IBM now would it?
No, I suppose it wouldn't. Your offhand dismissal aside, how will it be
able to be "the new standard" when it won't run on the majority of 386es
out there? If what you're saying is true, it won't be ported to EISA
machines, either. Actually though, since all the OSF customers will
have AIX, surely at least one of them will port it to AT bus-based 386es.
> So, everyone else in the near future will want AIX compatible code.
> I'm sure it will be. Yes I think you are right, IBM will become the
> dominant force in the UNIX market especially once they get their
> "real" AIX/370 out the door.
Is this schizophrenia? :-) It reads like you answered yourself.
> PS: "No. I do not work for IBM!"
...but you are a true believer!
--
-- uunet!ficc!karl "Contemptuous lights flashed across the computer's
-- ka...@ficc.uu.net console." -- Hitchhiker's Guide
Oleg Kiselev
>With binary compatibility, once you are convinced that
>two systems are, in fact, binary compatibile you don't need to waste
>time doing a complete from ground up system test on each hardware
>platform for each new release of the application.
I fail to see how binary compatibility solves the major problem of platform
migration -- how do you upgrade to a bigger machine? NFS and a set of
networked 386 boxes does not really replace having a much larger machine.
AIX PS/2 with TCF, goes to great length to present a single system image, while
addition of 370s provides the enormous processing and disk storage capacities
possible only on mini and mainframe computers.
One important segment of the UNIX market largely ignored until now are the
growing businesses, which, after investing time and money into software and
procedures of their UNIX system, run out of machine capabilities and need a
bigger and faster machine, or more login lines, or more disk storage. AIX
answers those needs. Yes, it involves a complete testing process on each
platform (and that's exactly what has already been done with AIX), but the
time investment is minimal -- most manufacturers have automated test suits
or well defined testing procedures to exercise their software and, given that
there is no porting necessary, except for very device-dependent and assembly
code, the process hardly becomes insurmountable.
Dick Dunn
In article <16...@gryphon.COM>, ol...@gryphon.COM (Oleg Kiselev) writes:
> I realize that this is an "i386" group and you are most interested in that
> processor, but AIX lives on not only 386, but on 370 as well (and, without
> LCC's enhancements, on RT).
>
> You are ignoring the obvious -- AIX is a cross-platform system.
This won't wash. When the first discussion of AIX PS/2 came up in this
group, people who had worked with AIX RT jumped up and started complaining
about all the alleged problems and deficiencies on the RT. They were
quickly corrected by folks who had worked on/with early versions of AIX
PS/2, pointing out that no, the PS/2 version had nearly complete 4.3
compatibility, long file names, etc. OK, good, AIX PS/2 is externally,
significantly different from AIX RT. Let's not forget that the AIX label
is also being applied to what IBM is delivering to OSF--a system which is
said to be radically different from the RT version.
Now AIX lives on 386, 370, RT. Which is it? You can't have it both ways--
either it IS the same system on all these platforms, or it isn't. Giving
it the same name doesn't make it the same system, or UNIX would really be a
cross-platform system! Pick one view or the other. From what I've read so
far, the more correct view seems to be that AIX is IBM's *name* for a group
of proprietary operating systems which are strongly based on UNIX. They
may all have some facilities in common, which are absent from other
variants of UNIX, but the same can be said for, say, 4.3 BSD systems
compared to other variants of UNIX...and that doesn't make 4.3 a "cross-
platform" system.
In any case, I *do* wish that people would be careful to say *which* AIX
they're talking about, particularly when lambasting or praising it.
--
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
...CAUTION: I get mean when my blood-capsaicin level gets low.
John Plocher
>widely available on the market.
Except SunOS (Ver 3.4 -> present) ... :-)
>How long has sV/386 been out? Give it time.
Microport has been shipping it for at least 2 1/2 years ...
>choose the former, but even if you do not, your hostility and vehemence are
>hardly justified.
I'd hope that more people would speak up and let their opinions be known
instead of rolling over and saying "Well, I guess that IBM really knows
what is best for me..." :-)
Let's see if I have gotten this straight:
Pro AIX PS/2:
1) Provides LCC's TCF to allow you to connect to your 370.
2) System Vr2 compatable AT THE SOURCE level
3) BSD 4.3 compatable AT THE SOURCE level
4) BSD 4.3 type user environment (jobs ...)
Con AIX PS/2:
1) not System Vr3 compatable AT THE SOURCE level
2) not V/386 System Vr3 compatable AT THE BINARY level
3) not V/386 System Vr2 compatable AT THE BINARY level
4) not V/286 System Vr2 compatable AT THE BINARY level
5) not System Vr2 compatable AT THE SYSTEM MANAGEMENT level
Summary:
Use your own weights on all of these points and make your
own decisions. If you have a 370 going to waste in the den,
AIX PS/2 sounds Great! if you have $$$'s invested in 386
applications that need 3.2 V/386 binary compatability, it
doesn't. In all, it sounds OK, just not what *I* am looking for.
>Oleg Kiselev ARPA: lcc....@seas.ucla.edu, ol...@gryphon.COM
-John Plocher
Rick Richardson
>>two systems are, in fact, binary compatibile you don't need to waste
>>time doing a complete from ground up system test on each hardware
>>platform for each new release of the application.
>
>migration -- how do you upgrade to a bigger machine?
It doesn't. It solves the problem of getting applications developers
to commit the time and money to produce high quality applications
and provide them at the lowest possible cost. Because they'll have
the biggest potential market.
This is more important to most 386 users than migrating to a 370
architecture machine.
When applications are needed on a larger machine, the package
cost is usually higher. High enough that the cost of doing the
port from source to the bigger machine is worth it, even if the
market is smaller.
As an aside, some of the RISCs have the potential to span nearly
the entire range of performance and cost with binary compatibility.
That is even more enticing to a software developer.
Chuck Karish
>Now AIX lives on 386, 370, RT. Which is it? You can't have it both ways--
>either it IS the same system on all these platforms, or it isn't. Giving
>it the same name doesn't make it the same system, or UNIX would really be a
>cross-platform system! Pick one view or the other. From what I've read so
>far, the more correct view seems to be that AIX is IBM's *name* for a group
>of proprietary operating systems which are strongly based on UNIX ...
They're developing something called the "AIX Family Definition"
that should say very clearly what AIX is. Maybe there are drawbacks
to IBM's current practice of releasing versions at different states
of development on different platforms. It seems to be more a
PR problem than a technical one.
IBM is committed to provide a well-defined porting base to OSF.
I expect that all their versions of AIX will be in sync with this
definition when it's delivered.
Chuck Karish {decwrl,hpda}!mindcrf!karish
(415) 493-7277 kar...@forel.stanford.edu
David F. Carlson
> >How long has sV/386 been out? Give it time.
>
> Microport has been shipping it for at least 2 1/2 years ...
John its not often I have cause to disagree with you, but...
Whereas *everyone* preannouced SV/386 (ie vapor) and beta units did go out
in the Summer of '87, Microport did not ship production SV/386 until
the Fall of '87 (~Oct) which is 1 1/2 years, (give or take a few months
but not 12! :-) )
--
David F. Carlson, Micropen, Inc.
micropen!da...@ee.rochester.edu
"The faster I go, the behinder I get." --Lewis Carroll
Oleg Kiselev
>This is vintage IBM mindset - the #1 priority is BUYING BIGGER IRON!
I do not represent either IBM or their mindset. I speak from experience.
You can not run 3380 drives on a 386, or 486, unless you do a lot of really
interesting hardware work. IBM's "big iron" is really what they say it is --
very fast, very reliable, capable of supporting over 200 users on a single
machine, capable of supporting enormous number and capacity of drives, etc.
Sometimes (and a lot more times than you seem to realize) it's the only
solution. Being able to provide a UNIX solution in this case is very
important. It allows IBM, as I see it, to compete with Amdahl and Cray as
a provider of big machines for number crunching, large model simulations
and transaction processing.
>Across same-CPU machines, full binary compatibility is a must. IBM doesn't
>want this because they want to lock in their market segment.
I have no idea what IBM wants. From what I have seen happen on the market
before, most software publishers will probably not hesitate to put in a few
thousands of dollars and a few man-weeks it takes to port and test an
application and to update the manuals. I used to work for a company which
supported its very large product on over 150 different systems, including
120 various flavours of UNIX and things like MS-DOS and VMS, so I know what
it's like to support multiple incompatible binaries. It's not all that
difficult, especially when the market segment you may be penetrating is quite
large.
>I would defend to the death IBM's right to do business this way. Just
>don't waste our time on the net pitching AIX as the future standard!
I do not pitch AIX as the future standard. I feel that AIX is an excellent
version of UNIX and can stand up to its competition. I also know that AIX is
quite usable and reliable and I would prefer it to a system V clone that does
not support the BSD-isms I am so accustomed to (real job control for one).
Whether or not AIX is a future standard is a moot point. UNIX will keep on
developing. The next step will probably be something that is heavily based
on MACH kernel AND uses streams for RPC/IPC system. 2 years from now,
something new will come up.
Locking yourself into the "standards" and "binary compatibility" mind-frame,
you are committing the sin of which so many people accuse IBM -- calcifying
into a inevitably obsolete technology and maintaining the compatibility with
it despite better paths of development.
Oleg Kiselev
>System Vr3 code should be able to cross-compile
>on ANY SysVr3 platform, be it IBM, 68000, SPARC, whatever.
That would not be BINARY COMPATIBLE, though! Horrors! Heresy! :-)
>If AIX, say, implemented streams, it would offer seamless porting...
As I said before, my understanding was that AT&T's source license language
made it very disadvantageous to someone who is trying to compete with them to
use "sVr3 compatibility". Also, if OSF is indeed going to go head-to-head
against Sun-AT&T group, allowing AT&T to declare at any moment that what you
have is not really UNIX (as sVr3 source license seemed to say), would have
been silly. sVr4 license is written differently. But I do not know what IBM
is planning to do about it.
daniel mocsny
> In article <10...@uceng.UC.EDU>, dmo...@uceng.UC.EDU (daniel mocsny) writes:
> > But if we are to advance beyond the
> > mainframe model of the 1960's, and make the computer into some sort of
>
> That's all very well, but that's not where IBM is coming from. They want
> to go back to the world of mainframes and corporate MIS departments. They
> have stated that they think PCs should be some sort of high-end smart
> terminal... see the article about SAA in the latest Infoworld.
I read the article. I also have to wonder how interested IBM is in
establishing a binary standard/mass market for 386-based UN|X given
its simultaneous interest in OS/2, a competing binary standard it
controls. However, I think if IBM wants to lock in customers and
compete on some basis other than price/performance/service, it is
making a mistake. On the one hand, IBM's accountants cannot fail to
notice that MIPS are now going for over $100,000 on a mainframe, $3000
on a CISC micro, and <$1,000 on a RISC. However, the demand for MIPS
is hardly static. It depends on the expected return the customer can
expect to generate after puchasing some iron. The net return depends
very strongly both on how much those MIPS cost, as well as software
availability. Since software development costs remain high while
hardware costs are dropping, the customer gets maximum value when the
software costs divide over the largest possible market. A homogenous
market therefore adds value to every participating vendor's machine.
The more value the customer gets, the more customers there will be.
If a fundamental limit exists on how many MIPS can be sold, I don't
know what it is. The more software customers can get, the more iron
they will buy. When everybody has iron, they need more iron to get
their iron talking to other iron. As application categories saturate,
software developers will have to become more creative, for example
they'll have to address more of the vertical markets. But whenever you
automate one task, customers go on to tackle new tasks. People don't
just sit there. They'll create as much value as they can. The more
MIPS they can get, the more opportunities they'll find.
The mainframe looks to me like an analogy of the railroad locomotive
in the late 1800's. Big, powerful, centralized, but not the most
flexible way to meet the needs of the individual. Because the railroad
required societies to organize themselves around its characteristics,
and not vice versa, its potential for economic growth had clear
limits. People had only so much time to wait at the station for the
train to arrive. Marginal economic opportunities couldn't justify
bringing in a railroad, so many projects could never get off the ground
at all. Incremental growth was difficult.
The desktop/side computer, on the other hand, is clearly analogous to
the automobile perhaps around 1910. It put unprecedented power and
mobility in the hands of the individual, but it suffered from lack of
standards, lack of supporting infrastructure (i.e., highways, parking,
service), and lack of widespread acceptance. Few people understood
where it was about to go, but it seems almost obvious in retrospect.
The railroad industries did not take the automobile seriously, with the
result that they did not share in its profit. Indeed, it hurt them.
IBM is doing better. It had a major role in establishing desktop
systems. It is also doing well with its Prodigy service, which is very
much like the efforts of the early automobile makers to lobby for
highway construction, except that IBM is not asking for a government
handout as the motor industry did before the gasoline tax became
significant. Without roads, the automobile is nearly useless. With
roads everywhere, the automobile is nearly necessary. Easy computer
access to public networks and massive software libraries will insure
that computers become a major obligatory purchase for everyone.
IBM therefore has a considerable say in how large its market can
ultimately become. If it really wants to become as wealthy as
possible, it will strive to create the most standardized and
homogenous market that it can. This is an essential aspect of social
engineering. IBM is now large enough that its performance not only
depends on the state of the overall economy, but it also has the power
to make that economy (and thus itself) larger.
Dan Mocsny
dmo...@uceng.uc.edu
Tom Neff
>migration -- how do you upgrade to a bigger machine? NFS and a set of
>networked 386 boxes does not really replace having a much larger machine.
>AIX PS/2 with TCF, goes to great length to present a single system image, while
>addition of 370s provides the enormous processing and disk storage capacities
>possible only on mini and mainframe computers.
This is vintage IBM mindset - the #1 priority is BUYING BIGGER IRON!
The fact is that with the proliferation of 386's, followed by the 486
and faster clock rate steppings of all parts, there is going to be
room to grow without radical platform migration for years to come. In
the percentage of cases where moving to a mainframe IS important,
*THAT* is when you trot out source level compatibility!! Across
same-CPU machines, full binary compatibility is a must. IBM doesn't
want this because they want to lock in their market segment. They may
get away with it too, bless their hearts -- the surviving cadre of MIS
priesthood will be happy to go along and reestablish CONTROL as in
days of yore! :-)
>One important segment of the UNIX market largely ignored until now are the
>growing businesses, which, after investing time and money into software and
>procedures of their UNIX system, run out of machine capabilities and need a
>bigger and faster machine, or more login lines, or more disk storage. AIX
>answers those needs.
Among others. AIX neither invented nor has sole possession of the answers.
> Yes, it involves a complete testing process on each
>platform (and that's exactly what has already been done with AIX), but the
>time investment is minimal -- most manufacturers have automated test suits
>or well defined testing procedures to exercise their software and, given that
>there is no porting necessary, except for very device-dependent and assembly
>code, the process hardly becomes insurmountable.
Categorically not the point. Yes one assumes the *OS* has itself been
ported OK (possibly a rash assumption with this vendor <grin>). Third
party application software has no such assurances. Of course IBM doesn't
make a dime on the aftermarket. It's just that this net has a lot of
people on it who *do* care about such things. If I write a UNIX Sys V 3.2
application to curses and so on, I can generate a 386 binary and ship
it to AT&T, Interactive, Bell Tech, Everex customers and more. Later
this year when SVR4 appears I can add SCO and Sun and others to the list.
But not AIX -- there I have to recompile and *hope* that this SVR2/BSD
mutant will do what I want.
I have talked to IBM sales reps about these issues on several occasions.
IBM has primed them to pitch the total IBM solution, and it's true that
if you eat, sleep, drink and breathe IBM all day long AIX seems like
pretty good stuff. Discussions about the rest of the universe of 386
and UNIX installations out there always seem to end up in a catatonic
stare. :-)
I would defend to the death IBM's right to do business this way. Just
don't waste our time on the net pitching AIX as the future standard!
--
Tom Neff UUCP: ...!uunet!bfmny0!tneff
"Truisms aren't everything." Internet: tn...@bfmny0.UU.NET
Oleg Kiselev
>OK, good, AIX PS/2 is externally, significantly different from AIX RT.
Actually, the way system is sold, the differences are mostly internal.
Externally, a person used to RT will very easily adapt to AIX PS/2. However,
all the 4.3 (and soon TCF) functionality are still there. (Just like a v7
user could pretend to be still using v7 on 4.3 BSD)
>From what I've read so
>far, the more correct view seems to be that AIX is IBM's *name* for a group
>of proprietary operating systems which are strongly based on UNIX.
AIX for PS/2 and 370 is pretty much the same OS. All aplications that do not
do device specific things use exactly the same code, compiled out of the same
source directory. RT provides the same applications level interfaces
(libraries and such), but (in current commercial release) lacks BSD
features. RT AIX will also not support TCF.
>In any case, I *do* wish that people would be careful to say *which* AIX
>they're talking about, particularly when lambasting or praising it.
I agree with that wholeheartedly.
Oleg Kiselev
>>How long has sV/386 been out? Give it time.
>Microport has been shipping it for at least 2 1/2 years ...
Which is why I believe that there is going to be a significant number of AIX
PS/2 3rd party applications showing up fairly soon. Remember when Mac had
no software to speak of? It takes a bit of time!
--
"No regrets, no apologies." -- Ronald Reagan
Oleg Kiselev ARPA: lcc....@seas.ucla.edu, ol...@gryphon.COM
(213)337-5230 UUCP:...!ucla-cs!lcc!oleg
Evan Leibovitch
>Do not judge IBM's attitude by my "feelings" -- I am not employed by IBM, nor
>have I been appointed their speaker. I am just expressing my opinion based
>on the facts known to me. If you really care about what IBM's attitude is,
>you should probably direct your questions to them.
Understood. I also realize there is a whole industry devoted to speculating
on IBM's goals and directions. Your analysis is clearer than most I've seen.
>"Open system" is not synonymous with "binary compatibility". IBM seems to be
>trying to achieve SOFTWARE compatibility between various hardware platforms.
>I realize that this is an "i386" group and you are most interested in that
>processor, but AIX lives on not only 386, but on 370 as well (and, without
>LCC's enhancements, on RT).
I don't see this as an issue. System Vr3 code should be able to cross-compile
on ANY SysVr3 platform, be it IBM, 68000, SPARC, whatever.
If AIX, say, implemented streams, it would offer seamless porting not only
to other Unix platforms available from IBM, but also to those sold by Unisys,
AT&T, Bull, Interactive, whatever. To me, that is what the concept of open
systems is all about.
>>IBM is forcing software developers to do two different software releases of
>>each product, if they want to cover the entire Unix-on-386 marketplace.
>(What about Sun? To run on Sun, one must do yet another port!)
Who said Sun was any better? The difference is, Sun has committed to
support SysVr4, so we know they'll be compatible then. Conversely, IBM
seems to thrive on the speculation about its actions.
>As long as software does not use streams and a few other sVr3-specific
>facilities, it should easily port to AIX. It does add to QA and packaging,
>but I am not sure how much.
To those trying to turn 386 Unix into a mass market, that means plenty.
Just like it's extra expense for a record store to stock LPs, CDs and
cassettes of the same record, it's also a pain for the entire distribution
channel having to create and market parallel versions of software. At a time
when Unix is trying desparately to get shrinkwrap software, this is a step
backwards.
>OS/2 and VMS do not run on 370 or RT.
So what? The list of systems which to not run AIX is much larger, both
in variety and installed base.
>porting
>system V and BSD applications to AIX is very easy and would hardly be a
>deterrent to software development.
Not easy, as some have pointed out, if the software to be ported uses
things like streams or the ETI.
>I do know that binary compatibility has not been an
>issue with UNIX before mass-proliferation of 386 boxes and I do know that an
>ability to run your software on a diverse class of machines seems quite
>important. IBM seems to be offering a UNIX which runs on machines from 386
>to the largest 370 and XA (3090, for example). I think we should be looking
>beyound binaries.
Watch out, folks. I think we're going to see all this replayed again if and
when OSF/1 ever gets released. I don't think the OSF buys into the concept
of ABIs, judging from its recent Request for Technology for an "Architecture
Neutral Distribution Format". This is bound to result in another reinvention
of the wheel :-(.
Peter da Silva
> mainframe model of the 1960's, and make the computer into some sort of
That's all very well, but that's not where IBM is coming from. They want
to go back to the world of mainframes and corporate MIS departments. They
have stated that they think PCs should be some sort of high-end smart
terminal... see the article about SAA in the latest Infoworld.
The emphasis on AIX/386 as a front-end for AIX/370 becomes considerably
more understandable in light of this article.
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: uunet.uu.net!ficc!peter, pe...@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, pe...@sugar.hackercorp.com.
Oleg Kiselev
>That's all very well, but that's not where IBM is coming from. They want
>to go back to the world of mainframes and corporate MIS departments. They
>have stated that they think PCs should be some sort of high-end smart
>terminal... see the article about SAA in the latest Infoworld.
Living in the world of personal work-stations and PCs, it is sometimes hard
to keep in mind just how enormous the "corporate MIS departments"
proliferation is. And how many installations with more than 8 users fall
into that category.
>The emphasis on AIX/386 as a front-end for AIX/370 becomes considerably
>more understandable in light of this article.
AIX PS/2 does indeed work marvelously as a user interface and local processor
for AIX 370, but that's in addition to, rather than instead of, being a very
good stand-alone workstation. The main thing, in my opinion, that AIX PS/2
offers (starting in the next release) is the LOCUS technology, called TCF by
IBM, that allows multiple machines to present a "single system image" to the
users and utilities. A completely transparent (for most purposes) and
nearly seamless linking of machines into a cluster goes beyond anything
awailable from a system like NFS or RFS. And such a setup is ideal for users
who need to keep adding users and devices without excessive expense of bying
a much bigger machine and/or rewriting/porting their software. With PS/2
AIX, buying a new PS/2, plugging it into the network and installing it, is
sufficient to add all those additional user login lines and disk space (as
well as the CPU cycles) into the cluster without any additional work needed
to be performed on any other site. All of the topology reconfiguration is
dynamic and built into the kernel.
I suggest you attend an AIX PS/2 (Gen 2) demo at the next UNIX show and
observe the process of a site dropping off the cluster (for any reason) and
joining it.
Fred Rump from home
>In article <8...@ultb.UUCP>, thw...@ultb.UUCP (T.H. White) writes:
->> your wimpy 386 box! If you would have invested in a PS/2 (not a
->> considerable amount more than a "good" 386 clone) and bought AIX for it,
->> you would now realize that AIX leaves these other 386 UNIX's in the
->> dust!
>
>This is a joke, right? First of all, I'm not sure what you define as a "good"
>clone, I guess a 33 MHz Compaq or something, but I bought a Mylex 4 MB 16 MHz
->> PS: "No. I do not work for IBM!"
I may have come in late to this discussion but I thought Theodore
White wrote history books. I believe in this case he's writing science fiction.
Whatever he's saying doesn't really deserve comment though. No sense to waste
bandwidth.
Fred
--
This is my house. My castle will get started right after I finish with news.
26 Warren St. ...{dsinc bpa uunet}!cdin-1!icdi10!fr
Beverly, NJ 08010 or INTERNET: fr...@cdin-1.uu.net or icdi10!f...@icdi10.uu.net
609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
Fred Rump from home
>I fail to see how binary compatibility solves the major problem of platform
>migration -- how do you upgrade to a bigger machine? NFS and a set of
>networked 386 boxes does not really replace having a much larger machine.
>AIX PS/2 with TCF, goes to great length to present a single system image, while
>addition of 370s provides the enormous processing and disk storage capacities
>possible only on mini and mainframe computers.
What planet are we on today? You'll be able to count the number of
370's running AIX all by yourself. You won't even need a PS/2 to help with the
numbers. Your comments are so crazy that I didn't think anybody on this net
could ever utter them. In this general world of mostly Intel boxes where IBM
is already down to 12.5% market share and sliding fast you see any hope of
AIX? The only places it'll find a home is with deyed in the wool IBM fans.
Mostly sub-shops of fortune 500 companies.
>
>One important segment of the UNIX market largely ignored until now are the
>growing businesses, which, after investing time and money into software and
>procedures of their UNIX system, run out of machine capabilities and need a
>bigger and faster machine, or more login lines, or more disk storage. AIX
>answers those needs. Yes, it involves a complete testing process on each
>platform (and that's exactly what has already been done with AIX), but the
>time investment is minimal -- most manufacturers have automated test suits
>or well defined testing procedures to exercise their software and, given that
>there is no porting necessary, except for very device-dependent and assembly
>code, the process hardly becomes insurmountable.
I won't delete any of the above. It needs to be seen to be believed.
These growing small businesses are not using IBM now nor will they in anything
even approaching propriatary hardware or software. Those days are over. Read
the press sometime. Read Business Week. Read anything for God's sake. Just
how much power are we looking for? Give me some numbers and I'll configure
you a system. How much disk you want. Number of terminals?
Have you ever heard of parallel processing? How many 486 chips will
fit in a box? The strange thing is the software will run on all of these.
I can today but a Zenith 1000 with 6 386's that'll run off the shelf Xenix.
100+ terminals on a micro? Heh, it's just beginning.
Why do you think OS/2 is such a bomb. What have they sold? 95,000
copies? This is with all the might and power of IBM and Microsoft. The market
wants generic standards and anybody who doesn't know that yet is doomed for a
big fall.
I wouldn't touch AIX with a ten-foot pole until it runs on the AT bus
for that $1000 386 box. That way my software investment of many years duration
will have a shot at bringing a return. Balderdash to AIX.
Fred Rump
>--
> "No regrets, no apologies." -- Ronald Reagan
>
>Oleg Kiselev ARPA: lcc....@seas.ucla.edu, ol...@gryphon.COM
>(213)337-5230 UUCP:...!ucla-cs!lcc!oleg
Fred Rump from home
>>This is vintage IBM mindset - the #1 priority is BUYING BIGGER IRON!
But never, never let a small inexpensive machine do anything useful
by itself except for one person at a time.
>
>I do not represent either IBM or their mindset. I speak from experience.
Your experience seems limited to the IBM scenario. What else do
you have to draw on?
>You can not run 3380 drives on a 386, or 486, unless you do a lot of really
>interesting hardware work. IBM's "big iron" is really what they say it is --
>very fast, very reliable, capable of supporting over 200 users on a single
>machine, capable of supporting enormous number and capacity of drives, etc.
Have you ever heard of mini-computers doing that years ago? Come to
Philadelphia sometime and I'll show you about 600 terminals tied into a few
inexpensive minis coupled together. A few gigabytes of disk should do it
right? Or are you into terrabytes for your 200 users? If you want to see some
really small iron producing great bottom lines I got about 4000 terminals to
go around running on little 6 inch boxes with typically 30 to 60 users on
line. I think you need an education about what the real world looks like out
here in small business land.
>>Across same-CPU machines, full binary compatibility is a must. IBM doesn't
>>want this because they want to lock in their market segment.
>
>I have no idea what IBM wants. From what I have seen happen on the market
>before, most software publishers will probably not hesitate to put in a few
>thousands of dollars and a few man-weeks it takes to port and test an
>application and to update the manuals.
This is more garbage. You need the hardware. You need to maintain many
sets of everything at tremendous cost of duplication.
>I used to work for a company which
>supported its very large product on over 150 different systems, including
>120 various flavors of UNIX and things like MS-DOS and VMS, so I know what
>it's like to support multiple incompatible binaries. It's not all that
>difficult, especially when the market segment you may be penetrating is quite
>large.
Where is this company now? You obviously learned very little there.
Anybody who has ever been in the software business to make money (and has to do
it charging today's dollars) will instinctively know that simplicity is the
key. Remember CP/M? How many flavors did we need? How many survived that
little fiasco? Differentiate that with DOS. Then take OS/2. They are still
crying for developers to take the plunge. And who wants it?
120 flavors of Unix! Ridiculous! Idiocy.
>>I would defend to the death IBM's right to do business this way. Just
>>don't waste our time on the net pitching AIX as the future standard!
>
>I do not pitch AIX as the future standard. I feel that AIX is an excellent
>version of UNIX and can stand up to its competition. I also know that AIX is
>quite usable and reliable and I would prefer it to a system V clone that does
>not support the BSD-isms I am so accustomed to (real job control for one).
Well, great. Just don't give us all this crap as to how you're basing
your decisions on any kind of experience. Some of us have to make a living
based real life situations and we can't afford to have our own little operating
system because we're accustomed to BSD'ism.
>Whether or not AIX is a future standard is a moot point. UNIX will keep on
>developing. The next step will probably be something that is heavily based
>on MACH kernel AND uses streams for RPC/IPC system. 2 years from now,
>something new will come up.
Yeah, if you don't have to put your balls on the line it's moot.
Otherwise it's a hell of an important point to be where the rest of the world
is. Unix will keep developing, obviously. But within a set of standards.
That's why we can invest our future into it. That point seems to have escaped
your mindset completely.
>Locking yourself into the "standards" and "binary compatibility" mind-frame,
>you are committing the sin of which so many people accuse IBM -- calcifying
>into a inevitably obsolete technology and maintaining the compatibility with
>it despite better paths of development.
Did anybody really say that? Locking yourself into standards! I guess
the opposite is opening yourself up to chaos. Wow! I don't know why I bother.
I think I need a better filter in this group for my blood pressure.
Fred Rump
Dave Kennard
> The most obvious factor is the micro-channel. This is the main performance
> difference between the two architectures. And , yes , the micro channel is
> superior. But with no second sourcing options and the ever present IBM
Apricot and Olivetti have MCA clones on the market (in UK anyway...)
--
+-+ +-+ +- | | Regards, Dave Kennard.
| | | | | |/ Dept. 30820, STC Telecommunications, Oakleigh Road South,
|-+ | | | |\ New Southgate, LONDON. N11 1LU, England, UK, (etc..)
| \ +-+ +- | |Voice (+44) 01-368-1234 x2860 <ro...@tcom.stc.co.uk>
Guy Harris
>>widely available on the market.
>
>Except SunOS (Ver 3.4 -> present) ... :-)
Well, it depends on what "widely available" means, since SunOS is only
sold on Suns, or what "4.3BSD system" means (there's a lot of stuff in
SunOS, kernel and user mode, that comes from S5 or from Sun)....
Also, try "Ver 4.0 -> present"; no streams in SunOS prior to 4.0.
Larry Campbell
">With binary compatibility, once you are convinced that
">two systems are, in fact, binary compatibile you don't need to waste
">time doing a complete from ground up system test on each hardware
">platform for each new release of the application.
"
"I fail to see how binary compatibility solves the major problem of platform
"migration -- how do you upgrade to a bigger machine? NFS and a set of
"networked 386 boxes does not really replace having a much larger machine.
"AIX PS/2 with TCF, goes to great length to present a single system image, while
"addition of 370s provides the enormous processing and disk storage capacities
"possible only on mini and mainframe computers.
The way binary compatibility solves the problem of upgrading to a bigger
machine is to have a binary compatible bigger machine! The VAX architecture
is a perfect example. It comes in sizes from desktop to mainframe, all
binary compatible (in user mode).
" ... Yes, it involves a complete testing process on each
"platform (and that's exactly what has already been done with AIX), but the
"time investment is minimal -- most manufacturers have automated test suits
"or well defined testing procedures to exercise their software and, given that
"there is no porting necessary, except for very device-dependent and assembly
"code, the process hardly becomes insurmountable.
Nonsense. The time investment, and money investment, are FAR from minimal.
Let's take a simple example. We're a small software house with an application
we want to sell.
We can develop it for, say, Ultrix, on our little MicroVAX-II, and have
an extremely high degree of confidence that our binary application will run
just fine on the biggest, meanest mainframe-sized VAX around.
But with AIX, we need to buy a PS/2 -- no big deal -- an RC/PC -- no big deal
either -- and an S/370 -- big big deal. Have you any idea what the smallest
usable 370 configuration costs to lease and maintain? And how much precious
floor space it takes up?
And this isn't just for the initial testing period either -- we can't just
test it once on a borrowed S/370 and then ship it for the next few years.
In order to support our customers, the way they expect and deserve to be
supported, we will have to have the S/370 available on our site for the
entire product lifetime. We're talking very big bux here -- which expense
we would NOT incur had we chosen VAXen as a platform.
And anyone who can say, with a straight face, that "there is no porting
necessary, except for very device-dependent and assembly code", is either
naive and inexperienced, or dishonest. In any major software project you
have to code around the compiler bugs, you have to code around the runtime
library bugs, and you have to worry about architecture-dependent things like
byte order, stack direction, and word size. I have worked on major projects
on many different architectures, under many different operating systems, and
my experience has been that EVERY compiler and EVERY runtime library has
bugs you must code around. If the project is big enough, there's NO SUCH
THING as a "straight port".
--
Larry Campbell The Boston Software Works, Inc.
camp...@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146
Oleg Kiselev
[developing for AIX]
>But with AIX, we need to buy a PS/2 -- no big deal -- an RC/PC -- no big deal
>either -- and an S/370 -- big big deal. Have you any idea what the smallest
>usable 370 configuration costs to lease and maintain? And how much precious
>floor space it takes up?
I have a very good idea how much an even small 370 costs, but that's one of
the points of AIX: unless your application is going to play with device
registers or some such, it will compile and run exactly the same on PS/2 and
on 370 AIX.
[Of course, a buggy program will sometimes behave differently on 370 and 386.
Trashed stack gives completely different results, sometimes what results in a
core dump on 370 just behaves strangely on 386 and vice versa. So a buggy
program which, say, misuses a pointer (say, stores a long to it and then
accesses through that long) can run on 386 satisfactorily with some occasional
"sporadic" failures and completely blow up on 370, but you can't blame AIX
for that.]
Another point of interest -- I am not aware of any purely 370 AIX cluster,
if you have a 370, you can easily afford a PS/2 to go along with it. In that
case, you will not need a 370 executable -- a 386 executable will be run on
PS/2 without the user having to know that it's happening.
>And anyone who can say, with a straight face, that "there is no porting
>necessary, except for very device-dependent and assembly code", is either
>naive and inexperienced, or dishonest. In any major software project you
>have to code around the compiler bugs, you have to code around the runtime
>library bugs, and you have to worry about architecture-dependent things like
>byte order, stack direction, and word size.
Well, you may be surprised. The compilers for AIX are fairly clean (both 370
and 386), word sizes are the same, stack growth direction should not matter
to a properly written C application which does not use any user-written
assembly code, for byte ordering AIX provides byte-flipping routines. Yes,
if you write your files in binary format (store longs and doubles without
converting them to some portable format), you might have to use the
byte-flipping code to deal with architectural differences. But then, the
code was not intended to produce portable data, to begin with.
>If the project is big enough, there's NO SUCH THING as a "straight port".
AIX ps/2 and 370 reduce the possibility of the problems you mention
(compiler and library bugs) happening.
Peter da Silva
> to keep in mind just how enormous the "corporate MIS departments"
> proliferation is. And how many installations with more than 8 users fall
> into that category.
Really? Consider how important the PC business has become to IBM.
> AIX PS/2 does indeed work marvelously as a user interface and local processor
> for AIX 370, but that's in addition to, rather than instead of, being a very
> good stand-alone workstation.
How is it at being a stand-alone departmental computer? You're still sitting
there in the IBM world of mainframes and workstations... while most of the
small computer business lives in between.
Peter da Silva
> made it very disadvantageous to someone who is trying to compete with them to
> use "sVr3 compatibility".
I firmly believe that if IBM took all the money they've spent on lawyers
and marketroids over this license issue, and spent it on a few very good
programmers, they'd have a completely AT&T-free clone of SVr3 or anything
else they want by now. You can't really expect us to have much sympathy
with IBM over the license issue.
Chuck Karish
(Evan Leibovitch) wrote:
[ lots of talk about the importance of binary compatibility ]
>Watch out, folks. I think we're going to see all this replayed again if and
>when OSF/1 ever gets released. I don't think the OSF buys into the concept
>of ABIs, judging from its recent Request for Technology for an "Architecture
>Neutral Distribution Format". This is bound to result in another reinvention
>of the wheel :-(.
I think the idea here is to provide an intermediate format that can be
translated into binaries to run on any of a number of different
architectures.
The architecture-neutral approach requires only that the operating
system's abstractions be the same on all the target platforms. Details
of the implementation can be handled in the translation software
for each target.
If it works, it'll mean that shrink wrap software will run on very
different machines, after being put through a preprocessor at
installation time. This sounds to me like a better idea than
committing to a particular chip, as is required under the ABI scheme.
It's also an approach that's likely to be well received by the OSF
membership (or the Unix International membership, for that matter),
who may not wish to restrict their development efforts to
machines based on widely-used chips.
It's not a replacement for an ABI, it's a higher-level standard.
Peter da Silva
> if you have a 370, you can easily afford a PS/2 to go along with it. In that
> case, you will not need a 370 executable -- a 386 executable will be run on
> PS/2 without the user having to know that it's happening.
This is an "interesting" statement.
If you're going to be running your application on your PS/2 anyway, what did
you want the 370 for?
Rick Richardson
>
>
>AIX ps/2 and 370 reduce the possibility of the problems you mention
>(compiler and library bugs) happening.
Assume that I can guarantee that my code contains not one whit
of unportable code.
Unless IBM guarantees, in writing, that its AIX compilers and
libraries will never contain bugs, I still have to test on the
370 architecture. I'd be a fool to do otherwise.
There is no advantage here for AIX, other than the claim of fewer
compiler bugs. I wonder if AIX mktg will put that down as a bullet
item. I can see the advert now:
Great Functionality!
Less Bugs!
Great Functionality!
Less Bugs!
Rick Richardson
>The architecture-neutral approach requires only that the operating
>system's abstractions be the same on all the target platforms. Details
>of the implementation can be handled in the translation software
>for each target.
This was all hashed out in comp.arch several months ago. The big gotcha
is that the application program has to be 100% portable to begin with.
To know that, you have to test on every architecture in the first place.
Consider that a 99% portable application might have one dereference
of a NULL pointer. On some architectures, the application will
continue to run, correctly, even with the dereference. On other
architectures it will core dump.
This approach saves the cost of inventoring various binaries for each
machine, but doesn't do anything for the portability, testing, or
support issues faced by software developers.
Bruce A. McIntyre
> In article <1...@odicon.UUCP> j...@odicon.UUCP (John L. Grzesiak) writes:
> > The most obvious factor is the micro-channel. This is the main performance
> > difference between the two architectures. And , yes , the micro channel is
> > superior. But with no second sourcing options and the ever present IBM
I keep hearing what a great crying need we all have for this fantastic
"NEW" architecture. What a great idea, bus mastering, etc. I bet no-one
ever thought of any of this before... Not Intel with MultiBusII, Not
Motorola with EuroBus, Nobody..eh? However, up until now, it seems that
there is no demonstrated performance improvement because of other re-
strictions in the system. The disk, the OS(PCDOS or OS/2),etc. But we
all NEED it, eh? So how come still, even the ones that have agreements
with IBM to "clone" the MC, still can't seem to actually SELL many?
I bet that if I really needed the performance of the MC, an IBM model
50 with a 16bit version will do anything I want, right? Not that the
EISA is any better.. It is a marginal re-hash of an outmoded system...
I will keep using my 386Clone as long as it pays for itself, when I will
immediatly trade up to whatever is the beast of the day... most likely
bet right now seems like a Sequent or Corollary/Zenith box...20 or 30
386/486 chips seems about right..
bruce
--
=========================================================================
Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895
143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915
{wells|lgnp1|prapc2}!mdi386!bruce bruce@wells tbit+
Unix, Xenix, Netware and PC-DOS Applications development.
Specializing in Database Applications since 1980.
Bill Vermillion
> 1) Provides LCC's TCF to allow you to connect to your 370.
> 2) System Vr2 compatable AT THE SOURCE level
> 3) BSD 4.3 compatable AT THE SOURCE level
> 4) BSD 4.3 type user environment (jobs ...)
John - I can think of one more Pro AIX. I saw it running at an IBM demo long
time ago, and don't know if it's in the current release.
TCF allows(ed) you to connect multiple PS/2s together. The other systems
could mirror some or all of the primary system. It seemed like a good way to
distribute a data base system to keep the most used parts in the departments
that need it, yet give everyone access. And it also looked like a way to
build a qausi-fault-tolerant system. Again - this was at a demo before it's
real release so I don't know current state.
bill
--
Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill
: bi...@bilver.UUCP
Oleg Kiselev
IBM practically created PC business, with Lotus' help. Only when IBM started
selling small desktop machines which ran spreadsheet software to people in
$800 suits who always wear silk ties, did the personal computing become
marketable. So IBM did SOMETHING right.
>How is it [PS/2 with AIX] at being a stand-alone departmental computer?
Just fine. A PS/2 AIX with 8 users is not the fastest thing around, but you
easily get 6-8 times the performance of a VAX 11/750 out of a 16MHz 386 box
(the data from some informal and scientifically inadmissible testing done one
a quiet evening). PS/2 performs as well or better than other comparable 386
machines (same clock rate, same memory, same drive access speed)
I suggest you refer to the benchmarks published by various UNIX magazines.
Oleg Kiselev
>you want the 370 for?
Disk storage. LOTS of disk storage. Losts of very FAST disk storage. Take
a look at IBM's mainframe drive specs, they are impressive. Using a 370 as a
file server shared by multiple PS/2's and appearing to a UNIX application as
just another UNIX file system is ONE thing you can do with 370.
Other possibilities: cycle serving, vectorized fortran, simulations, etc.
What do people use large 370s for?
And the best reason of all -- if you already have a 370. And a lot of people
do.
Oleg Kiselev
That would be a foolish thing to do, now wouldn't it? We all know there is
no such thing as non-trivial program which is totally debugged. AIX comes
with very extensively and intensively tested code. That's all anyone can
possibly guarrantee.
James da Silva
>>Consider how important the PC business has become to IBM.
>
>IBM practically created PC business, with Lotus' help. Only when IBM started
>selling small desktop machines which ran spreadsheet software to people in
>$800 suits who always wear silk ties, did the personal computing become
>marketable. So IBM did SOMETHING right.
Well, it certainly seems that way now, especially if you read a lot of IBM
oriented magazines, but it just wasn't like that.
I used to work for a BIG IBM mainframe oriented software house. The first
personal computers to infiltrate the offices (that I know of; twas before
my time there) were Apple ][+'s running Visicalc. This was before the IBM
PC came to market. I can imagine the first encounter with an IBM
salesthing: "Hey, what kind of terminal is this? It's not an IBM! What's
going on here?".
Anyway, IBM did NOT create the PC market. They waited for it to take off,
then jumped on the bandwagon with a very conservative Apple ][ spinoff
machine (16-64k, cassette port, ROM BASIC, optional single-sided disk
drives). Yes, they did "legitimize" the PC for those with a "you can't get
fired for buying IBM" mindset.
Lotus came around a bit later. If anyone created the IBM-PC-Compatible
market, it was Lotus, not IBM.
Just nitpicking.
Jaime (no relation to Peter)
...........................................................................
: domain: j...@mimsy.umd.edu James da Silva
: path: uunet!mimsy!jds
GPUNIX Super User
AIC (Apricot In Canada) Computers Inc. is the exclusive North American
distributor for Apricot. Their (my) phone number is (416) 492-2777.
Michael Herman uucp: utgpu!alias!pic!michael
Product Manager CCO: Michael Herman
AIC (Apricot In Canada) Computers Inc.
Peter da Silva
> >Consider how important the PC business has become to IBM.
> IBM practically created PC business, with Lotus' help. Only when IBM started
> selling small desktop machines which ran spreadsheet software to people in
> $800 suits who always wear silk ties, did the personal computing become
> marketable. So IBM did SOMETHING right.
I suppose I should traditionally interject something here to the effect of
"What's that in that pipe you're smoking?", but that could be construed as
a flame. I'll just point out that I suspect you're pushing (or passing on)
some revisionist history.
There was a thriving PC industry with dozens of competing manufacturers
each trying to outdo the others. Then IBM came in, and it was 5 years before
you could again run PC software on a cheap multitasking system. The whole
PC development cycle came to a screeching halt as IBM's heavy-duty marketing
department turned its FUD-guns on the market. It wasn't until 1985 when the
Amiga came out that a genuinely new operating system became available on
a cheap PC without said PC becoming a total failure.
IBM did something, all right.
Peter da Silva
> >If you're going to be running your application on your PS/2 anyway, what did
> >you want the 370 for?
> Disk storage. LOTS of disk storage. Losts of very FAST disk storage. Take
> a look at IBM's mainframe drive specs, they are impressive. Using a 370 as a
> file server shared by multiple PS/2's and appearing to a UNIX application as
> just another UNIX file system is ONE thing you can do with 370.
I can get a 300 megabyte drive and controller for a conventional IBM-clone
for well under $2000. If I need more than a couple of those I'm a pretty
specialised market, now aren't I? That's not who IBM's targeting the PS/2
for.
> Other possibilities: cycle serving, vectorized fortran, simulations, etc.
> What do people use large 370s for?
According to IBM's ads, accounting. :->.
There are cheaper ways of getting lots of fast CPU cycles than a 370.
> And the best reason of all -- if you already have a 370. And a lot of people
> do.
That's a valid reason. OK, if you already have a 370... get a PS/2. Everyone
else... SysV/386 and a 386-based AT clone.
Jim Frost
|In article <16...@gryphon.COM> ol...@gryphon.COM (Oleg Kiselev) writes:
|>In article <43...@ficc.uu.net> pe...@ficc.uu.net (Peter da Silva) writes:
|>>Consider how important the PC business has become to IBM.
|>
|>IBM practically created PC business, with Lotus' help.
|
|then jumped on the bandwagon with a very conservative Apple ][ spinoff
|machine (16-64k, cassette port, ROM BASIC, optional single-sided disk
|drives).
Actually the first IBM "PC" was called the System/23 Datamaster. It
had two 8" floppies, ROM BASIC (the screwiest BASIC I've ever seen,
and I've seen a LOT of them), 128k (I think, hard to tell), and spoke
EBCDIC. You'd recognize the keyboard, it's precisely the original IBM
PC keyboard except the Alt key was a command key and all the function
keys performed system functions.
The thing had standard IBM error messages (ie it beeped, gave a number
to look up the error in, then you hit a clear-error button to
continue) and was slower than anything I've ever seen, before or
since.
It's possible that no one reading this has ever seen such a beast;
they were a huge flop and IBM backed off them immediately. IBM isn't
always successful.
jim frost
software tool & die
ma...@bu-it.bu.edu
Jim Frost
IBM lost face with the PC, and the PC has eroded some markets which
IBM had found very profitable (eg System/36), but the PC market
amounts for very little of IBM's income.
I'm not sure what IBM has up their sleeve, but if I were them I'd try
very hard to make PCs the terminal of the '90's.
Fred Rump from home
>In article <17...@mimsy.UUCP> j...@mimsy.umd.edu (James da Silva) writes:
>|In article <16...@gryphon.COM> ol...@gryphon.COM (Oleg Kiselev) writes:
>|>>Consider how important the PC business has become to IBM.
>Actually the first IBM "PC" was called the System/23 Datamaster. It
>had two 8" floppies, ROM BASIC (the screwiest BASIC I've ever seen,
>and I've seen a LOT of them), 128k (I think, hard to tell), and spoke
>
>It's possible that no one reading this has ever seen such a beast;
>they were a huge flop and IBM backed off them immediately. IBM isn't
>always successful.
These things are still in use. They were 8085 based were they not?
As far as IBM's success ratio? Well, the investment in mainframe hardware
- software was so great that business had to find safety in numbers with one
vendor. But from there, IBM blew it with every other proprietary box it made.
The only real success with ANY small system they ever made is the lowly open
system PC. And then they had to compete which hurt their margins. This forced
retrenching to MCA and controlled competition. If memory serves me correctly
that still leaves about 10% of IBM's revenue in micros. This in turn is about
their marketshare. The numbers are small for IBM but huge in anybody else's
dictionary.
It's still the world champion computer company. But they let so much more get
away!
Fred
Richard Foulk
} In article <15...@vail.ICO.ISC.COM> r...@ico.ISC.COM (Dick Dunn) writes:
} >From the rumors I've heard, I might believe that IBM would have
} >been unwilling to sign a license under the V.3 terms, but how does that
} >imply that they couldn't have been compatible with the object format?
}
} I am not sure of the exact reasons. It COULD have been a time and effort
} issue ( Given the incredible amount of QA IBM does on the software, it
^^^^^^^
Somebody's shoveling it a bit deep around here.
Peter da Silva
> I'm not sure what IBM has up their sleeve, but if I were them I'd try
> very hard to make PCs the terminal of the '90's.
Oh, so would I. That's why (1) I'm not surprised that they're doing it,
and (2) I am surprised when I see people claiming otherwise.
Of course one can understand a sin without condoning it.
Dick Dunn
> It's not a replacement for an ABI, it's a higher-level standard.
This much is true, and it would conceivably make sense to have the ANDF
"compiler" for a particular architecture produce code in the ABI for that
architecture. The one thing that ABIs and ANDF have in common is that they
are intended to be distribution formats for software, and there is a real
possibility of competition between them.
ABIs and ANDF are very different in an important respect: The idea of an
ABI is trivial; there's nothing to invent. It's nothing but an agreement
that everyone on a particular architecture will use the same conventions.
ANDF, however, is currently a speculative problem statement. Consider that
two of the admitted possible solutions are a compiler-intermediate language
and encrypted source, and you can see how far they have to go to converge
on it. They've got a problem statement, and that's ALL they have right
now. OSF is pretty up front about this, by the way.
Don't look to ANDF to supply any answers to near-term problems. OSF's
timetable says that in January, 1990, they will begin feasability studies
of leading candidates. They won't announce until then the schedule for the
final selection. That says they are being careful not to schedule inven-
tion. They require that the final product be ready for shipment during
1990, but all things considered it's likely to be late 1990, so figure
about two years from now before it's really useful (IF it works out).
Better believe in ABIs in the meantime.
> ev...@telly.on.ca (Evan Leibovitch) wrote:
> >Watch out, folks. I think we're going to see all this replayed again if and
> >when OSF/1 ever gets released. I don't think the OSF buys into the concept
> >of ABIs, judging from its recent Request for Technology for an "Architecture
> >Neutral Distribution Format". This is bound to result in another reinvention
> >of the wheel :-(.
My guess is that OSF would like ANDF to supersede ABIs--why market software
for a particular architecture if you can market it for any architecture.
back to Chuck Karish:
> The architecture-neutral approach requires only that the operating
> system's abstractions be the same on all the target platforms. Details
> of the implementation can be handled in the translation software
> for each target.
The idea is that you buy an ANDF "compiler" (whatever that really means)
for your machine; then you can buy any shrink-wrapped software, run it
through the compiler, and you've got a working program. This requires a
lot more than standardizing the operating system's abstractions. It
requires some major magic to make a workable runtime system which will
support a reasonable set of languages. It requires a completely clean,
absolute boundary between machine-independent and machine-dependent parts
of the translation process (including macros, optimizations, runtime
libraries, etc.) It requires complete portability of programs packaged in
ANDF--and that includes portability to processors to be designed in the
future.
> If it works, it'll mean that shrink wrap software will run on very
> different machines, after being put through a preprocessor at
> installation time. This sounds to me like a better idea than
> committing to a particular chip, as is required under the ABI scheme.
Sure, but the key phrase is "If it works..." At present, there is no
choice between ANDF and ABI, because ANDF doesn't exist. Not only is it
not clear when it will exist; it is not clear whether it can exist (in the
sense of a practical technology implementing the requirements of the RFT).
Although I can see the advantages of ANDF, it seems to me that OSF is
rather premature in advertising the advantages of something that hasn't
been invented yet! (Would you prefer an alternative to the automobile
which was also self-powered but did not produce any pollution, was com-
pletely safe, and guided itself without relying on a human operator? Sure!
We can even give it a name...but that won't make it exist.)
I hate to be so negative about this without indicating some reasons. (I
don't mind being negative _per_se.:-) Of the two likely approaches that
have seen some general discussion, both have serious problems. The
encrypted source code poses major problems in preventing decryption when
everyone has a program which contains the decryption algorithm. It also
pushes the bulk of the translation process to the machine-dependent side of
the ANDF interface, which gives an unfortunate replication of the trans-
lation steps (for each possible language) to each target. The other
likely approach--a compiled intermediate form--seems to evoke the same
reaction from every serious language/compiler/portability person I've
talked to so far: It's the UNCOL problem all over again (in spades), so
they're not interested in it. (UNCOL = UNiversal Compiler-Oriented
Language, a problem which has been kicking around for thirty years or so.
It is most notable for the number of top-notch people who have worked on
it, solved a substantial part of it, and then given up when the complete
solution wouldn't work--usually because it collapsed of its own size and
complexity trying to cover all the cases and get the level(s) of abstrac-
tion in the right place(s).)
Summary: ANDF is an interesting idea, but so was UNCOL. I don't know of
any reasonable approach to a solution. That's not to say it can't happen,
but that's not where I put my money. ABI, on the other hand, is tech-
nically trivial. It works if you can get people talking to one another,
and that has happened.
--
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
...CAUTION: I get mean when my blood-capsaicin level gets low.
Larry Campbell
-I'm not sure what IBM has up their sleeve, but if I were them I'd try
-very hard to make PCs the terminal of the '90's.
What do you mean? The PC *is* the terminal of the '90s. (By PC I mean
anything running MS-DOS; UNIX on a 386 is really almost a workstation.)
An MS-DOS machine makes a nice semi-intelligent terminal, but not much else.
David C. Rein
> In article <16...@gryphon.COM>, ol...@gryphon.COM (Oleg Kiselev) writes:
>> Another point of interest -- I am not aware of any purely 370 AIX cluster,
>> if you have a 370, you can easily afford a PS/2 to go along with it. In that
>> case, you will not need a 370 executable -- a 386 executable will be run on
>> PS/2 without the user having to know that it's happening.
>
> This is an "interesting" statement.
>
> If you're going to be running your application on your PS/2 anyway, what did
> you want the 370 for?
Well, for one thing, you could take adavantage of the huge amounts of
storage available on 370 systems (as oleg pointed out before). Also,
since many companies have 370 software, if you run AIX on a 370 VM, you could
develop programs to interact between the 370 OS and AIX, allowing for a
more flexable environment for end users. I have used such a system for
problem tracking on a very large project. Problems tracked on VM interacted
with some SCCS commands on AIX, allowing for a greatly detailed problem
tracking system.
Conversely,having the 386 executables just allows for a larger amount of program
availability to the end user. Since some programs most probably won't be ported
to a 370, 370 AIX users can run a 386 program on a 386 site without letting the
user deal with it.
--
Disclaimer: The above opinions are my own, since no one else would claim them.
Dave Rein
UUCP: uunet!ism780c!kodak!gizzmo!\ "It just goes to show what you can do
lazlo!mobile!dave if you're a total psychotic"
Internet: dcr0801@ritcv -- Woody Allen
karl lehenbauer
> few smart terminals to it.
> Everyone with a 370, hands up...
...and if you are already running a ton of applications under CMS, TSO, etc,
and would have to host AIX/370 as yet another operating system under VM, lower
your hand. The point is that people who have already have 370s are already
running stuff other than AIX, and tho' the machine may run both simultaneously,
they will be worlds apart. IBM, too, will have little incentive to push AIX
onto any customers who are already heavily into 370s and 3270s and their other
existing proprietary software environments.
By the way, we have 200 programmers at this site, *lots* of networked non-MCA
386es...and no 370s. While there are no doubt many IBM 370s out there, they
are hardly dominate in the scientific and engineering communities, which is
where most Unix systems will still be found. Consequently, although AIX/386
may be successful, the ability to use 370s as 386 back-ends will not be a
compelling reason for most existing Unix customers to switch.
How many MIPS is that mainframe, anyway? 50? 80? How many people am I
going to have to share them with? Mainframe MIPS are the most expensive
MIPS there are. Except for people with applications that need more than
15 MIPS or so, workstations are the way. Further, many of the high-MIPS
applications involve interactive graphics. Could a 370 back-ending a 386,
at a cost of millions of dollars, begin to approach the performance of a
Stellar or Ardent box? ...and is there any software? Few single-task-single-
thread applications are so computationally intensive and worthwhile that
someone would dedicate a mainframe to them, and when they do, it's usually
a supercomputer, and Unix compatibility isn't really high on their list, as
development cost is typically a fraction of the recurring execution costs in
this case.
Disk storage? That big Sun disk server supports something like 40 GB.
Few will need more. That leaves you with the people who need more than
40 GB of storage and those who need to get at it faster than their VME
backplane, SCSI interface, network or what-have-you will allow. Granted,
some will need it, but how many?
--
-- uunet!ficc!karl "Contemptuous lights flashed across the computer's
-- ka...@ficc.uu.net console." -- Hitchhiker's Guide
Peter da Silva
> In article <43...@ficc.uu.net>, pe...@ficc.uu.net (Peter da Silva) writes:
> > If you're going to be running your application on your PS/2 anyway, what did
> > you want the 370 for?
> Well, for one thing, you could take adavantage of the huge amounts of
> storage available on 370 systems. Also, since many companies have 370
> software, if you run AIX on a 370 VM, you could develop programs to
> interact between the 370 OS and AIX, allowing for a more flexable
> environment for end users...
(albeit a less portable one)
So, basically, AIX is for people who already have a 370 and want to add a
few smart terminals to it.
Everyone with a 370, hands up...
David C. Rein
> It's possible that no one reading this has ever seen such a beast;
> they were a huge flop and IBM backed off them immediately. IBM isn't
> always successful.
Very True!! The IBM System/9000 and System/23 must of came from the same
scrap heap. The 9000 was another IBM machine that crashed and burned. It
also had 8" floppies (*SLOW*), and needed an 8" planer Mickey Mouse Unit (MMU)
to run a version of Xenix. I was using an extensive System/9000 with two
floppies, two hard drives, and the MMU...for a 4800 baud terminal!
Dave Rein
Disclaimer: The opinions expressed above are my own, etc...
UUCP: ..!kodak!gizzmo!lazlo!\ \/ "It just goes to show what you can do
mobile!dave /\ if you're a total psychotic"
Domain: dcr0801@ritcv / \ -- Woody Allen
karl lehenbauer
> I know it is dreadfully dull, and not very popular to state on Usenet,
> but the vast majority of heavy duty computing is still done in
> monsterous computing centers using COBOL and such on 370's.
> That is the market IBM is addressing with AIX/370 and TCF.
Granted that MIS departments do a lot of heavy computing. For some of them,
AIX/386 and AIX/370 may contain some compelling capabilities. I merely
asserted that 370s weren't that popular in scientific/engineering circles and
that, consequently, 370 compatibility is not an overwhelming reason to choose
AIX over Unix.
Regarding Oleg Kislev's seeming fanaticism, Peter da Silva remarked in
passing (quoted with permission, though):
"Nobody who isn't a sales slut at heart would be pushing AIX
that hard."
A. Lester Buck
> In article <43...@ficc.uu.net>, pe...@ficc.uu.net (Peter da Silva) writes:
> > So, basically, AIX is for people who already have a 370 and want to add a
> > few smart terminals to it.
>
> > Everyone with a 370, hands up...
>
>...and if you are already running a ton of applications under CMS, TSO, etc,
>and would have to host AIX/370 as yet another operating system under VM, lower
>your hand. The point is that people who have already have 370s are already
>running stuff other than AIX, and tho' the machine may run both simultaneously,
>they will be worlds apart. IBM, too, will have little incentive to push AIX
>onto any customers who are already heavily into 370s and 3270s and their other
>existing proprietary software environments.
True, since they will make less money, but some customers are demanding Unix.
IBM doesn't have to push it to them.
> By the way, we have 200 programmers at this site, *lots* of networked non-MCA
> 386es...and no 370s. While there are no doubt many IBM 370s out there, they
> are hardly dominate in the scientific and engineering communities, which is
> where most Unix systems will still be found. Consequently, although AIX/386
> may be successful, the ability to use 370s as 386 back-ends will not be a
> compelling reason for most existing Unix customers to switch.
Maybe a 370 cross-compiler would speed up your software development. :-)
IBM didn't generate $60 billion in revenue last year from scientific and
engineering communities - they dominate in business applications.
If AIX/370 takes only 20% of the mainframe business, it could swamp
all the rest of Unix sales combined. And TCF is of great
interest to 370 customers because, among other things, it appears to offer
truly effective load balancing across an array of 370's.
> How many MIPS is that mainframe, anyway? 50? 80? How many people am I
> going to have to share them with? Mainframe MIPS are the most expensive
> MIPS there are. Except for people with applications that need more than
> 15 MIPS or so, workstations are the way. Further, many of the high-MIPS
> applications involve interactive graphics. Could a 370 back-ending a 386,
> at a cost of millions of dollars, begin to approach the performance of a
> Stellar or Ardent box? ...and is there any software? Few single-task-single-
> thread applications are so computationally intensive and worthwhile that
> someone would dedicate a mainframe to them, and when they do, it's usually
> a supercomputer, and Unix compatibility isn't really high on their list, as
> development cost is typically a fraction of the recurring execution costs in
> this case.
It is just the other way around - the computationally intensive tasks
now go to dedicated PC's or RISC machines, or even specially designed
processors to solve difficult physical systems. You buy a mainframe
(as opposed to a supercomputer) for one big reason - I/O bandwidth.
The ability to keep (say) 24 channels at 4.5 MB/sec reasonably busy is
a truly awesome feat. See the recent issue of MIPS magazine that
had an interview with Gene Amdahl about the architectural differences
between PC's and mainframes. Machines that can handle massive I/O
are still very expensive to design, though we can hope that PC's and
mainframes will continue to converge in silicon.
> Disk storage? That big Sun disk server supports something like 40 GB.
> Few will need more. That leaves you with the people who need more than
> 40 GB of storage and those who need to get at it faster than their VME
> backplane, SCSI interface, network or what-have-you will allow. Granted,
> some will need it, but how many?
Oh, say > 90% of businesses that are big enough to have MIS departments.
I know it is dreadfully dull, and not very popular to state on Usenet,
but the vast majority of heavy duty computing is still done in
monsterous computing centers using COBOL and such on 370's.
That is the market IBM is addressing with AIX/370 and TCF.
And if they succeed, we someday just might have a bunch of Usenet hands
raised when Peter asks for 370 sites.
> -- uunet!ficc!karl "Contemptuous lights flashed across the computer's
> -- ka...@ficc.uu.net console." -- Hitchhiker's Guide
--
A. Lester Buck ...!texbell!moray!siswat!buck
Tom Neff
AIX issue. What started as an opinionated AND technical inquiry has
sort of degenerated into personal slagging. I don't care who started
it etc etc -- can we mutually stop it? :-)
It seems to me we really are arguing two separate issues here. One is
the general proposition "AIX performance is terrific" versus "AIX
performance su**s". This question is complicated by the track records
of past and present versions of AIX for the RT and PS/2 (and 370
although I haven't seen anything like a benchmark for AIX/370). It's
alleged the performance is improved with current versions and, hey
folks, I give IBM that much credit at least. I'm sure it's fast by now
or will be soon for all the applicable platforms. IBM muscle may have
its limitations but optimizing performance isn't one of them.
The other issue, and the thorny one for me, is compatibility versus
traditional IBM market locking. Protestations in this newsgroup to the
contrary, it does look to me as though we're witnessing a corporate
battle of the giants here between IBM and AT&T. Surely that's how IBM
sees it. AT&T wants to promulgate its own standard -- is promulgating
it, hell, HAS promulgated it. Sys V/386 is a mature reality that runs
on a multiplicity of iron, compatibly with other SysV's. (AT&T have
hurt themselves here by failing to make the effort to support it on
other than their own hardware - folks like Interactive want to do it
for you but corporate America cannot be blamed for raising an
eyebrow.) Anyway if you're IBM this is anathema to you. IBM didn't get
where it is by embellishing others' standards. They like to DEFINE
things. When the market pushes something on them, as it has with UNIX,
they don't seem to react well. They want to make those sales while
somehow twisting things to where they run the show. Who can blame them
from a Harvard Business School point of view? AIX seems a classic
foray along these lines. Yes you can have UNIX functionality, on your
IBM iron thank you very much! :-)
I respect Oleg's hard work and careful postings here (I will extend
the same laurels to Mr. White when he earns them <grin>) but I don't
think there's any percentage in fooling ourselves. IBM could have
COFF/ABI 386 binary compatibility if it wanted it. It doesn't. Open
systems interchangeability across the hated AT&T hardware is not is
IBM's perceived interest. As an unaffiliated person I would absolutely
run away from recommending AIX for any installation that didn't
already own a stock of PS/2's and 370's. (For an installation that did
own such a stock I would unconditionally recommend AIX. Ok Oleg?!
<grin>) For the "little guy" IBM wears the black hat on this issue and
AT&T seems to wear the white hat for the moment. (Remember that in
1980 it was proprietary Apple in the black hat and open IBM in the
white - so nothing's permanent.)
--
Tom Neff UUCP: ...!uunet!bfmny0!tneff
"Truisms aren't everything." Internet: tn...@bfmny0.UU.NET
Oleg Kiselev
>>I do not represent either IBM or their mindset. I speak from experience.
> Your experience seems limited to the IBM scenario. What else do
> you have to draw on?
I have been using UNIX for the last 7 years and have been doing commerical
UNIX development (on all levels, as applications programmer and as a member
of a UNIX porting team) for at least 4 years.
> Have you ever heard of mini-computers doing that years ago? Come to
>Philadelphia sometime and I'll show you about 600 terminals tied into a few
>inexpensive minis coupled together.
IBM line includes minis. 43** series is minis, so are 9370. The latter are
also not all that expenisve and can support a large number of drives.
However, the difference with AIX is that the 370 box can be transparently
tied with the PS/2's (and appear and behave as a single system with some
features of parallelism -- something NFS and RFS do NOT do). I have used
networked minis and I have used AIX PS/2 and 370 clusters. The latter is a
lot easier to use and offers a lot benefits not available on the former.
>I think you need an education about what the real world looks like out
>here in small business land.
I have worked with a lot of different UNIX systems, Mr. Rump, you have no
idea who I am and what my expertise may be. Also your conceited arrogance
is really grating. I think you need an education about the subject we are
discussing here -- you obviously have no idea what PS/2 and 370 AIX offer,
or, for that matter, what AIX is. I suggest you pick up this year's UNIFORUM
paper on TCF and take a look at AIX vs other 386 UNIX benchmarks before you
reply to this article.
>> most software publishers will probably not hesitate to put in a few
>>thousands of dollars and a few man-weeks it takes to port and test an
>>application and to update the manuals.
> This is more garbage. You need the hardware. You need to maintain many
>sets of everything at tremendous cost of duplication.
A 386 PS/2 (mod 70 or 80) costs under $12,000 fully loaded -- retail. OEMs
usually get their hardware much cheaper. Do you have experience porting
something to a number of versions of UNIX, Mr. Rump? I do. So I know what
I am talking about. And having a leaflet-insert for system specific
directions is hardly a "tremendous cost".
>>I used to work for a company which
>>supported its very large product on over 150 different systems, including
>>120 various flavors of UNIX and things like MS-DOS and VMS, so I know what
>>it's like to support multiple incompatible binaries. It's not all that
>>difficult, especially when the market segment you may be penetrating is quite
>>large.
> Where is this company now? You obviously learned very little there.
That company is still has the 3rd largest base of installed UNIX software in
the world and offers the top selling multi-ligual Office Automation package in
Europe and US. I have learned quite a bit there and have contributed quite a
bit to their success. My professional and georgraphic preferences caused me
to leave them. That is not a reflection on their business success or on my
ability to "learn".
> 120 flavors of Unix! Ridiculous! Idiocy.
That is the "idiocy" of the market we live in. There are a lot of different
processors out there, in the real world, Mr. Rump, and a lot of different
versions of UNIX running on them. It may seem "ridiculous" to you, but to
succeed in business sometimes one must play by the rules of market. I invite
you to list all the hardware UNIX lives on and all the supported versions of
those UNIXes out in the field. To succeed, you have to be able to offer your
product on as many platforms as possible.
If you don't like that, stick to writing your code for CP/M and for sVr3.
Your market will, of course, be limited.
>...Just don't give us all this crap as to how you're basing
>your decisions on any kind of experience.
Mr.Rump, I suspect my experience is not any less valid than yours. So don't
you give me this crap about "real world" -- I know what the real world is
like.
>I don't know why I bother.
I know I will not nother with you anymore, Mr. Rump. You are a crass and
argumentative shit -- and, unlike some other crass and argumentative people
in this group, you don't have the knowledge of the subject you are trying to
denigrate. I think you are a waste of time.
John Plocher
| argumentative shit -- and, unlike some other crass and argumentative people
| in this group, you don't have the knowledge of the subject you are trying to
| denigrate.
Well, uh, ummm, I guess that was a complement. Thank you. :-)
-John Plocher
PS. What does this have to do with unix on a 386?
PPS. Whew, 22 new messages in comp.unix.i386 - and all from the *same* guy! I wish
I had that sort of time!
Dick Dunn
> issue of "UNIX REVIEW". The benchmarks, as well as the "per-$" performance,
> seem to be quite unambiguous...
So what if they're unambiguous...Are they RIGHT? I don't know about the
general accuracy, but I tried Dhrystone on corax, which is a Compaq 386/25
running 386/ix, and got a Dhrystone value =>30% different<= from the one
quoted in UNIX Review! I've double-checked my test; I've also run
Dhrystone on various machines and I have a fair idea where the 386/25
should fit. Dhrystone isn't that hard to run; it's really hard to blow it
that badly. However, if UNIX Review blew it once, they could have done it
more than once. Beware.
Also, it's *not* the case that the PS/2 came out on top throughout, as
you might think Oleg is hinting. Note, for example, the test on sequent-
ial disk transfer rate, where the Compaq with 386/ix is a factor of 2-2.5
faster than the PS/2 AIX.
The "per-$" performance figures are primarily for the hardware. It's
unfortunate that they only tested the cheapest hardware (ALR) with SCO; if
the other results are consistent (regardless of absolute correctness), the
ALR machine with 386/ix would have come up a much better buy. In fact, in
general the Compaq is nice but it's pretty pricey for a 386 AT-style
machine...I think you could find a similar setup from smaller (but still
reputable) vendors for 2/3 the price, perhaps less. That would alter
price-performance quite a bit.
daniel mocsny
> In article <16...@gryphon.COM> ol...@gryphon.COM (Oleg Kiselev) writes:
> >you are committing the sin of which so many people accuse IBM -- calcifying
> >into a inevitably obsolete technology and maintaining the compatibility with
> >it despite better paths of development.
>
> Did anybody really say that? Locking yourself into standards! I guess
> the opposite is opening yourself up to chaos. Wow! I don't know why I bother.
> I think I need a better filter in this group for my blood pressure.
Do standards inevitably cause industries to calcify into obsolete
technology? Suppose we journey to the plains of Shinar and build a
tower of bricks reaching to heaven. (That's the Tower of Babel, for
those without a reading familiarity with the Book of Genesis.) Look,
God Himself knows what standards can do, he even said something like
"The Sons of Men are all of one tongue and one purpose, and now
nothing shall be impossible for them." So the Ancient of Days had to
step in and give us the wonderful gift of cultural diversity, to add
such a whopping translation overhead on every information transaction
that we bogged down forever into chaos and warfare.
But I digress. ;-)
Oleg and Fred seem to be arguing about two different things. Oleg
fears obsolescence, and Fred fears chaos. To clear up the reasons for
their disagreement, I propose that we analyze the trend that opposes
standards: fragmentation. Let us define fragmentation as any
development that causes humans to change the way they program and use
computers. Obviously, since computers are still incredibly stupid
pieces of hardware, they are virtually unable to tolerate any sort of
fragmentation on their own. They need inputs that are highly structured
according to explicit rules, and whenever the input changes, some human
has to intervene to clean things up. Thus to a very good approximation,
the difficulty humans have in getting incredibly stupid hardware to
do anything useful is a function of how much fragmentation exists in
the environment where that hardware is used.
We can classify fragmentation into two types: horizontal and vertical.
1. Vertical fragmentation is an inescapable part of technological
progress. If we compare the 8085 to the 80386 or a MIPS RISC CPU, we
can hardly expect to transparently preserve our entire intellectual
investment in the 8085 when we move up to new hardware with vastly
greater underlying capability. The bloodshed involved in upgrading is
highly variable. Since computers are in theory general-purpose
information processors, with the appropriate software tools the user
can "mine" old information and use it on new hardware. Nonetheless,
when hardware advances become revolutionary enough we eventually have
to throw out some of our old standards. In this case we face a clear
trade between the cost of junking our investment in our earlier ways
of doing things vs. foregoing the potential benefits of new and better
hardware. The bigger the previous investment, the bigger the benefits
of upgrading have to be before vertical fragmentation is justifiable.
2. Horizontal fragmentation results from market manipulation, the whim
of vendors, sheer incompetence, contempt for users, or the inability
of rival vendors to communicate. I'm talking about nonsense like
having 50 MS-DOS programs that each somehow find a different function
key to provide on-line help. I'm talking about differences between
products that make them incompatible and inconsistent while providing
no clear-cut technical advantage. Horizontal fragmentation vastly
increases the intellectual burden separating computer users from
solving their problems. Since it decreases the value of the computer
to the user while providing no offsetting benefit, it makes the
computer market smaller. This must eventually translate on average
into smaller paychecks for everyone who has tied their fortune to that
market.
Introducing UN|X into the MS-DOS world creates fragmentation, but this
is clearly in the vertical direction because the technical advantages
of UN|X are obvious. Having 120 flavors of UN|X creates horizontal
fragmentation, because the technical differences between the flavors
are usually quite minor compared to the disaster they create for users
and software developers. Oleg mentioned earlier that supporting a
single large package on each flavor of UN|X would cost (ideally)
several thousand dollars and several man-weeks per release per flavor.
Others have called this estimate low, claiming that the developer has
to have every targeted box in-house to realistically support a
package.
Even if Oleg's estimate is correct, it immediately destroys the chance
for small developers to enter the market profitably, since it imposes
effectively a "fragmentation tax" of at least a quarter million
dollars to cover the broad class of UN|X flavors. If we add up this
fragmentation tax over the thousands of major applications typical of
a mature operating environment, we will see that horizontal
fragmentation is costing developers alone into the billions. The loss
to users consists of higher software prices and software that never
reaches the market in the first place, not to mention retraining
costs, re-keying, re-programming, data conversion, etc., and must be
proportionately higher than the loss to developers. Are we talking
tens of billions per year?
Dan Mocsny
dmo...@uceng.uc.edu
Oleg Kiselev
>(For an installation that did own such a stock [of PS/2 and 370s]
>I would unconditionally recommend AIX. Ok Oleg?!
I agree with you on this -- the existing investement in hardware will
determine the selection of UNIX to run on it. IBM is not selling AIX that
will run on any 386 other than PS/2. It would have been quite interesting
if they did, but I would rather not speculate on IBM's marketing strategies
(if only because I want to keep my job :-).
BTW, how big is the total hardware and OS combined market for sVr3 on 386?
I mean, what is the approximate (very rough) $$$ figure on, say, year of
hardware and UNIX port sales in this market? Just curious...
Oleg Kiselev
>asserted that 370s weren't that popular in scientific/engineering circles and
>that, consequently, 370 compatibility is not an overwhelming reason to choose
>AIX over Unix.
The major reason for AIX/370 was the high-$$$ demand for very big simulation
environments. In particular, Intel bought their bunch of 3090's to run
an early pre-release version of AIX/370 (0.1) so they could design 80486
and other top-of-the-line processors. They needed the ability to run
200 Mbyte-size simulation processes. The AIX/370 cluster was their solution.
It obviously worked quite well.
It's not 370 compatibility itself, but rather the advantages of "mainframe
MIPS" that AIX/370 offers.
>Regarding Oleg Kislev's seeming fanaticism, Peter da Silva remarked in
>passing (quoted with permission, though):
> "Nobody who isn't a sales slut at heart would be pushing AIX
> that hard."
I am a part of the team that is responsible for AIX/PS2 and AIX/370
existence. I *know* what the strengths and weaknesses of AIX are from
*inside*, as a member of the team who wrote and ported the software, and from
*outside*, as a someone who has to use the system every day.
For comparisons of AIX/PS2 with other 386 UNIX ports, please refer to May
issue of "UNIX REVIEW". The benchmarks, as well as the "per-$" performance,
seem to be quite unambiguous. It simply confirms what those in this group
who have used AIX/PS2 have been trying to tell you -- it works and works
quite well.
Oleg Kiselev
>running 386/ix, and got a Dhrystone value =>30% different<= from the one
>quoted in UNIX Review!
I thought UNIX REVIEW used a 20 MHZ machine. I don't have the article in
front of me...
>Also, it's *not* the case that the PS/2 came out on top throughout, as
>you might think Oleg is hinting. Note, for example, the test on sequent-
>ial disk transfer rate, where the Compaq with 386/ix is a factor of 2-2.5
>faster than the PS/2 AIX.
Actually, I was more interested in the comparisons of performance only on
PS/2 -- there were 3 different UNIX ports tested on PS/2, including ISC's.
It is preformance on that platform -- without distortions of different drive
and controller combinations and technologies -- that make AIX look really
impressive.
I will not argue with your assertion that 386/ix on ALR machine would have
been faster and cheaper -- it is quite possible it would be. If you put
together your own 386 box, you will probably get it to be even cheaper yet
and quite possibly 386/ix will run on that too -- AIX, as is (or as IBM is
likely to sell it), will not (it runs ONLY on PS/2).
However, on PS/2 AIX proved to be a worthy competition.
Rick Richardson
>>I tried Dhrystone on corax, which is a Compaq 386/25
>>running 386/ix, and got a Dhrystone value =>30% different<= from the one
>>quoted in UNIX Review!
>PS/2 -- there were 3 different UNIX ports tested on PS/2, including ISC's.
>It is preformance on that platform -- without distortions of different drive
>and controller combinations and technologies -- that make AIX look really
>impressive.
OK, before everybody goes off and looks at the UNIX review article,
I'd like to point out that UNIX review does not identify the Dhrystone
version used in the tests. Based upon the information I have, it
appears to be version 1.1, which was obsoleted last summer by 2.1.
2.1 generally shows results that are 10-30% less than 1.1 numbers.
Furthermore, Dhrystone 2.1 goes to greater lengths to keep compiler
optimizers from changing the instruction frequencies that are
intended.
It is clear, then, that the AIX standard compiler is able to do a
better job of optimizing the Dhrystone 1.1. I'm sure that some
of this improvement carries over to real programs, but it is
pretty unlikely that all of it does.
Also, the article fails to mention the version numbers of the
operating systems tested. One comment in the text implies that
the ISC 386/ix version tested was 1.0.6. Of course, those of us with
ISC 386/ix 2.0 and later have noticed marked disk performance improvements,
due to changes in both the drivers and the filesystem itself.
Under the 1.0.6 version, 3:1 interleave was optimum for the disk
controller we use. Under 2.0, 1:1 interleave can be used with the
same controller to get much better performance.
The bottom line, for me, is that this review has little credibility.
The software tested was old, and some of the tests used are obsolete.
And yes, Oleg is correct. You have to compare the PS/2 70 figures
across the board, since that machine is the only common denominator
for all three UNIXes tested.
--
Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2
PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2
uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms.
jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
John Plocher
| I mean, what is the approximate (very rough) $$$ figure on, say, year of
| hardware and UNIX port sales in this market? Just curious...
Several hardware vendors I have talked to have mentioned shipping
THOUSANDS of 286 & 386 systems a day (Big mail order houses)
Bell Tech, Microport, ISC, Everex, Dell, SCO, & IBM all sell Unix
and mostly do well at it. This shows that there is enough of a
market to support them.
Off The Cuff guesses at yearly PC Unix Software gross:
Microport $ 5M - $ 10M +- 2M V/386 3.0
Bell Tech: $ 10M - $ 15M +- 2M V/386 3.0 3.2
ISC: $ 10M - $ 20M +- 5M V/386 3.0 3.2
Everex: $ 10M - $ 20M +- 5M V/386 3.0 3.2
Dell: $ ? ? V/386 3.0 3.2
SCO: $300M - $500M +- 200M Xenix 2.3
IBM: $ 20M - $ 50M +- 50M Xenix 2.0 & AIX/2
Very Rough estimates:
Low end $350M - $600M
High end $600M - $850M
Thinking about this, a 1/2 Billion+ market seems awfully small - I
would expect something closer to 2-3 Billion.
What I know about Microport is out of date. BT, Everex, ISC, SCO and
IBM are just guesses - and not very good ones at that.
-John Plocher
Owner
Having played a bit with AIX I would not be so quick to damn it. However,
the statements made here recently do hold significant merit:
Proprietary Architectures are GOING to die if they attempt to bind the user
community to Proprietary versions of operating systems.
IBM and others need to become aware that a computer is just a platform to
do work on. If the work can be done better/cheaper/faster etc. on another
box it will occur.
The great groundswell of users moving to generic operating systems which
can run on a great diversity of generic platforms will cause the proprietary
folk to lose market share in the near term.
This is being posted from a generic box (sorry Northgate :-) ). An 80386
running at 25 mhz with 256k of static cache. A 6 mip+ machine in my very
own home! Now fairly affordable by the working class... So why would
anyone spend >4k$ more for a PS-2? And then spend more big $ every time
they want to add a peripheral or card? (My system is running ALL of the
cards and peripherals that ran on my XT!!!). (to be really sick I have
to mention that with XENIX 386, VPIX, and Z80MU I can even run my
original CP/M stuff on this baby, while others use it too...)
Cheap MIPS for the masses...
--
Steven P. Donegan These opinions are given on MY time, not
Area Telecommunications Engineer Western Digital's - They wouldn't agree!
Western Digital Corp.
stanton!donegan || don...@stanton.UUCP || donegan%stanton@UUCP
karl lehenbauer
It's stuff like this, "run our 'nonproprietary' operating system, but only
on our proprietary bus" that has given IBM the reputation of trying to lock
users into expensive, proprietary solutions.
Since IBM is the major driving force behind OS/2, it is easy to see AIX as
an attempt to snare the people who seek a portable operating system by which
they can avoid being locked-in to a particular architecture.
That is not to say that AIX is not a good OS; I can't make that judgment at
this time. However, it clearly introduces incompatibilities (for example,
by not being binary-compatible with System V, even V/2, right?) and support,
prices and functionality are subject to change at IBM's whim.
IBM has only recently embraced the concept of open systems. I question their
commitment, particularly when one of their first acts is to define a new,
incompatible "open system standard"...DEC too, for that matter, or has Olsen
now stopped calling Unix "snake oil."
As a guy who owns a personal Unix system, and this would apply to any company
or individual with a small computer budget, my ability to afford to run Unix
(or AIX) could be destroyed by large price increases in upgrades, etc.
That is not to say that AT&T is kind and benevolent, either. System V/4 will
be expensive. It has a lot of things I don't particularly need. And there
isn't supposed to be a cheap upgrade from V/3.2.
I think POSIX might be the answer, for me and others on tight budgets, if
POSIX implementations become available from software vendors other than the
"big two." GNU could be the way, if it ever becomes available. Regrettably,
the redistribution criteria are restrictive in ways that'll probably prevent
GNU from ever more than a "hacker's OS."
--
John Plocher
>IBM has only recently embraced the concept of open systems. I question their
>commitment, particularly when one of their first acts is to define a new,
>incompatible "open system standard"...DEC too, for that matter, or has Olsen
>now stopped calling Unix "snake oil."
Quoting from a Digital Review article clipping (no date/issue):
CANNES, France -- VMS is
more compliant with the specifi-
cations of the Open Software
Foundation (OSF) than any other
operating system avaliable today.
DEC President Kenneth Olsen
Day 2, DECWorld Show
Not snake oil, exactly....
Male bovine animal droppings
-John Plocher
Chuck Karish
>In article <16...@gryphon.COM>, ol...@gryphon.COM (Oleg Kiselev) writes:
>> IBM is not selling AIX that will run on any 386 other than PS/2.
>
>It's stuff like this, "run our 'nonproprietary' operating system, but only
>on our proprietary bus" that has given IBM the reputation of trying to lock
>users into expensive, proprietary solutions.
After IBM delivers AIX to OSF, other vendors will be able to offer it
on other hardware. One of the reasons that OSF chose AIX for their
porting base was that the redistribution license was cheaper.
>Since IBM is the major driving force behind OS/2, it is easy to see AIX as
>an attempt to snare the people who seek a portable operating system by which
>they can avoid being locked-in to a particular architecture.
People who choose Interactive or SCO aren't locked in to the Intel/EISA
architecture? They're betting that 386 boxes will be good enough, for
the forseeable future, or that future Intel chips will provide the most
attractive upgrade path. If the next really attractive hot chip comes
from MIPS or Motorola or AMD or whoever, they (we) will have to decide
whether they like being locked in.
>That is not to say that AIX is not a good OS; I can't make that judgment at
>this time. However, it clearly introduces incompatibilities (for example,
>by not being binary-compatible with System V, even V/2, right?)
Before the current crop of System 5.3 ports was released, binary
compatibility between different implementations was not an issue; it
just didn't exist. If you wanted binary compatibility, you stayed
with one vendor.
>and support,
>prices and functionality are subject to change at IBM's whim.
The present AT&T/OSF feud grew out of AT&T's attempt to enforce such
a whim on their clients. Both camps seem to have learned a lesson from
that debacle; it won't happen again soon.
>I think POSIX might be the answer, for me and others on tight budgets, if
>POSIX implementations become available from software vendors other than the
>"big two."
Most of the incompatibility gripes posted here have been about 5.2 vs.
5.3 issues, which aren't covered by POSIX at all. If you can get by
with a system that provides little more than POSIX 1003.1 and 1003.2
support, you don't have the problems people have ben describing here.
Note, too, that POSIX doesn't define a binary interface. If you go
with an independent POSIX implementation, only the programs for which
you have source are guaranteed to be portable.
--
My employer produces software for IBM. Neither he nor IBM will
stand behind what I write.
Chuck Karish {decwrl,hpda}!mindcrf!karish
(415) 493-7277 kar...@forel.stanford.edu
Steve Dyer
>After IBM delivers AIX to OSF, other vendors will be able to offer it
>on other hardware. One of the reasons that OSF chose AIX for their
>porting base was that the redistribution license was cheaper.
Cheaper than what? May I remind you that AT&T will be getting a slice of
every copy of AIX/OSF-1 sold.
>Before the current crop of System 5.3 ports was released, binary
>compatibility between different implementations was not an issue; it
>just didn't exist. If you wanted binary compatibility, you stayed
>with one vendor.
We're talking about a phenomenon which started 3 years ago. It's no less
unfortunate that IBM decided that this wasn't important for something
released in 1989.
--
Steve Dyer
dy...@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dy...@arktouros.mit.edu
Oleg Kiselev
>There is already a PS/2 version of SCO. I think Interactive has one, as well.
I invite you to bench-mark them against AIX. Or see UNIX Review (May? June?)
for comparisons.