jay@metran.UUCP (Jay Ts) (04/26/91)
[This post is very difficult for me to write, but I feel so strongly that it has to be done, that I am having to accept the fact that a lot of you reading this are going to be offended. There's not much I can do about that except to not write, and I find that to be an unacceptable cop-out.] A few days ago, I referred to the recently-formed ACE alliance, made up of such industry heavyweights as DEC, SCO, Microsoft, MIPS and Compaq. The group is planning to form standards for the MIPS RISC architecture similar to what 88open has been doing for the 88k, but with some major differences. This got me thinking, so I posted a question: "Does 88open define a hardware standard that would allow a company to develop a UNIX port to run unmodified on all 88open-compliant machines?" The answer is: "No." A few of those who replied to my post went on to explain that 88open's standards applied to software only -- the interface between third party software and the operating system. This is very difficult for me to accept. It seems to me that an "open" standard that applies to software but not hardware is really only 1/2 open. After all, a major reason why the PC-compatible market caught on and flourished (and still is flourishing) is because at the introduction of the machine, IBM released documentation on the PC's expansion bus, allowing other companies to develop and market expansion hardware for the PC. Because the PC was so simple and easy to copy, the clone makers produced PC-compatible motherboards and other parts. This "second source" of parts is essential to VARs, systems integrators and other resellers who are in the business of providing the best available solutions for their customers. At the hardware level, that is what Open Systems is all about. (Another thing that bothers me about the lack of an 88open hardware standard is that the customers end up being tied to their system vendor for the operating system, so the lack of hardware standard bleeds through to the software side as well. Also, not only do the customers end up with no second source for hardware parts, but they are also tied to the vendor's support contract as well. So maybe it's less than 1/2 ...) Now I'm going to do something to really strike a nerve. Let's look at the competition: architecture sales volume standards ----------------------------------------- PC-compatibles massive open hardware and software; "de facto" industry standard. SPARC huge open hardware and software; formal standard - SPARC International MIPS big none right now; open hardware and software standards planned as part of ACE alliance. 88k big open software formal standards -- 88open IBM, HP big none; hardware is not even easily cloned. I am saying "big" for the last three because I'm not sure of the exact numbers. To give some idea, both IBM and Data General sell only about 1/10 (very approximately) the quantity that Sun does. The difference between Sun and the PC compatibles is also about 1:10 (also *very* approximately...). My point is that the 88k is much nearer the bottom than the top, and that the main 88k vendor at this point, Data General, is not as big and powerful as IBM or HP. Thus, the 88open companies simply cannot afford to remain in the proprietary segment. On the other hand, DEC *is* big and powerful, and for some reason, they are very interested in the ACE alliance. Maybe they are starting to catch on. I sense that there is a resistance to a hardware standard in the 88open members, because they are afraid of competition from other 88open vendors forcing them into the so-called "commodity" hardware market. To this, I have two things to say. First, a commodity, according to my dictionary, is simply an article of trade. There is nothing wrong in selling commodities; it's simply a common, fundamental and necessary part of maintaining the human system of life. Being in the commodities market is *good*, because it is where the lifeblood of the economy is. Second, any good company can not only survive, but have great success in such a market. The PC compatible market looks scary, until you realize that it's just a big testing ground; computer evolution in progress, where adaptation and natural selection are the rules. The companies who do the best job find the most success. There's nothing wrong with that. To continue with the evolution analogy, I think that what is happening in the computer market market is like what happened a few million years ago with animals; the age of dinosaurs (proprietary systems) gave way to the age of mammals (Open Systems). Still, in these days of "little mammals" there are animals like elephants and whales roaming the earth. They are just as big as the dinosaurs were. People (and especially corporate management) continue to find extra value in products that are soundly developed and supported by large companies, and are happy to pay extra money for them. If they aren't, I will be happy to talk them into it :-) What this is boiling down to is that I am urging the 88open members to IMMEDIATELY begin work on the 88k hardware standard. I really like the 88k and want very much to see it succeed. I feel that the 88k machines deserve to sell in greater quantity than any other machine now on the market, and think it would be a terrible shame if five years from now this were not the case. In the future, I want to be supporting, and maybe even selling, 88k-based open hardware/software solutions. At present, I find it hard to even recommend them to my clients. As I see it, the 88k is now suffering mostly from improper support from the very companies that are attempting to use it for their own gain, and would like to point out that there is much more to be gained from a more open attitude. Thank You Very Much for reading this far. If you work for a member of the 88open Consortium Ltd., please do me a favor and send a copy of this message to your 88open representative and/or other policy-making personnel. Jay Ts, Director Metran Technology 14100 N. 46th St., Z-29 Tampa FL 33613 (813) 979-9169 uunet!pdn!tscs!metran!jay
jtc@motcad.portal.com (J.T. Conklin) (04/27/91)
In article <16@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >A few days ago, I referred to the recently-formed ACE alliance, made up >of such industry heavyweights as DEC, SCO, Microsoft, MIPS and Compaq. >The group is planning to form standards for the MIPS RISC architecture >similar to what 88open has been doing for the 88k, but with some major >differences. This got me thinking, so I posted a question: "Does 88open >define a hardware standard that would allow a company to develop a UNIX >port to run unmodified on all 88open-compliant machines?" > >The answer is: "No." A few of those who replied to my post went on to >explain that 88open's standards applied to software only -- the interface >between third party software and the operating system. I don't know if this is true. I am able to run binaries compiled on a Motorola MPC on a DG Aviion and binaries compiled on the Avvion in the m88kbcs development environment. In fact, I used the Aviion almost exclusively to generate binaries for the MPC since Motorola's development tools are hideous. In fact, software written to the BCS/OCS standard will not necessarily compile on the MPC. For example, in /usr/include/string.h: /* * OCS says to typedef size_t here. That causes too many problems * for folks wanting to include sys/types.h. * * typedef unsigned int size_t; * */ Rather than protecting the typedef with the standard practice of #ifndef's and #defines. Motorola decided to ignore OCS and not define size_t. It takes a lot of header file editing to make a usable Motorola MPC. Back to the Aviion. It does a great job -- but it could be made a lot better. For example, it supplies the core OCS/BCS libraries in the m88kbcs environment, but not the BCS networking supplement. Since the product I am working on uses a network license server, I had to go back to the MPC :-(. If DG supplied these libraries, I wouldn't have to touch a MPC again :-). Getting back to the subject. As far as I know, BCS binaries should run on any 88open BCS complient box. But it is very easy for a application to step over the bounds of BCS and become dependant on machine or vendor specific feature. You should have no problems if you are careful. -- J.T. Conklin jtc@motcad.portal.com, ...!portal!motcad!jtc
mash@mips.com (John Mashey) (04/27/91)
In article <1991Apr26.184514.21951@motcad.portal.com> jtc@motcad.portal.com (J.T. Conklin) writes: >In article <16@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >>A few days ago, I referred to the recently-formed ACE alliance, made up >>of such industry heavyweights as DEC, SCO, Microsoft, MIPS and Compaq. >>The group is planning to form standards for the MIPS RISC architecture >>similar to what 88open has been doing for the 88k, but with some major >>differences. This got me thinking, so I posted a question: "Does 88open >>define a hardware standard that would allow a company to develop a UNIX >>port to run unmodified on all 88open-compliant machines?" >>The answer is: "No." A few of those who replied to my post went on to >>explain that 88open's standards applied to software only -- the interface >>between third party software and the operating system. > >I don't know if this is true. I am able to run binaries compiled on a >Motorola MPC on a DG Aviion and binaries compiled on the Avvion in the >m88kbcs development environment. I think Jay and J.T. are talking about different levels of things, and since ACE was mentioned as the start of this, let me explain exactly what is and isn't going on. 1) J.T. was talking about being able to run the same binaries of applications on various different machines from different vendors. This is what you get from: 88Open SPARC clones (running SunOS versions) Various people who use RISC/os in MIPS world. ACE(1): under ODT, or any OS that will run those binaries ACE(2): under OS/2 3.0 (NT) 2) What Jay was asking about, was the part of ACE that says that shrink-wrapped OPERATING SYSTEMS [ODT, OS/2 3.0] would run across multiple vendors' machines, if they complied with an appropriate set of specifications [which turns out to include things like minimum necessary stuff to boot, media interchange formats, keyboard layouts, etc ... but NOT I/O bus, so that you can have busless, EISA, TurboChannel, etc, etc systems, and still be able to run the shrink-wrapped operating systems. (Note, of course, that such things already exist in the MSDOS, etc. & SCO ODT worlds, and usually within any single vendor's product lines, you often have a base kernel that can boot on most, if not all machines in that product line, although you may well reconfigure to throw out and/or add device drivers.) Anyway, this is hardly a strange concept; it is certainly easier to do when you start from scratch and think about it :-) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650
quirk@quokka.rtp.dg.com (Peter Quirk) (04/27/91)
I think that Jay has misinterpreted the intentions of the 88open,
and grossly underestimated the size of the task involved in
producing a Shrink-wrapped UNIX for 88K systems that would serve
the great bulk of users.
What sets the 88K apart from the other architectures is:
1. a highly scalable multiprocessor architecture
2. the lack of an I/O bus standard
3. an absolute commitment to binary compatibility over multiple
system platforms, over versions of UNIX, and over generations
of the chip architecture.
4. a working certification process for binary compatibility.
5. a binary compatibility standard based on international and de facto
standards.
The first attribute attracts systems vendors like Data General who
believe that customers like to grow their systems painlessly over
time without changing architectures. It's also a boon to vendors
because it minimizes the effort to manage a broad product line.
The second attribute attracts system vendors like Data General who
can apply their systems design skills to build balanced systems
at all levels of scale. Using standard buses one could use SCSI and EISA
at the low-end, VME in the mid-range, VME-64 higher-up and maybe
Futurebus+ or SCI at the top end. All these systems would be open,
would have access to appropriate I/O peripherals for their performance
characteristics, and would not be constrained by a bus decision
targetted at the desktop. All that is necessary for user applications
to migrate across these platforms is a workable binary standard.
The third attribute is the glue that binds the 88open together and makes
us potentially very large. While it is true that Sun, HP and IBM lead
us in market share, it is also true that Sun was there a long time before
us, and HP and IBM are very large, resourceful companies. We count
amongst our membership some large and some resourceful companies who
have not yet announced their products.
The fourth attribute, a working certification process for binary
compatibility on very different hardware platforms, is something
MIPS has failed dismally to achieve (due in large part to DEC's desire
to be proprietary); IBM and HP are not interested (having
architectures no-one else has licensed); and Sun has yet to deliver one.
The PC of course has no binary standard certification process, and you
can never be sure whether your binary will work with all vendors' PCs.
That's because there is no spec for the hardware, and no certification
process for well-behaved programs under DOS or Windows. The VGA "standard"
is a joke (you've got to know which chip is used in the graphics card),
and the ever-changing memory model and windowing interface have caused
lots of big software companies lots of grief.
The 88K BCS of course is based on the SVID, POSIX 1003.1, BSD UNIX,
X Windows, sockets, and TLI to date, and is evolving. The only other
shrink-wrap "standard" is DOS & Windows and that's based on nothing.
The SunOS binary standard (for Sparc) is not based on POSIX, so if you
want to run your existing V.3 binary on a V.4 SunOS platform (when it
eventually ships), your system calls are going to be trapped by an
intermediate layer of runtime molasses that correctly maps your V.3
process behavior onto the POSIX model. Sun estimates this will cost you
a 10% performance hit. You can of course avoid this by buying new
compilers and building a new executable, but it won't run on the old
systems (a real drag of you're in the business of selling shrink-wrap
software).
Now if you insist that 88open is backward in providing a standard HW
interface so that software vendors can produce shrik-wrap UNIX operating
systems for all 88K systems I would simply observe the following:
1. The presence of a perceived open HW standard in the PC has not
resulted in any significant operating system offerings apart from
DOS (DrDOS included).
2. The market for alternative, totally compatible, operating systems
on anyone's box is minimal. The software market is for applications,
and to a very small extent I/O drivers. This is where the 88K could
benefit from an instantiation of the SV.4 DDI/DKI standard, once
USL has revised it to meet the needs of multi-processor and secure
systems vendors.
--
------------------------------------------------------------------------
Peter Quirk Internet: quirk@quokka.webo.dg.com
Data General Corporation Phone: +1 (508)898 4679
3400 Computer Drive Fax: +1 (508)898 2684
Westboro, MA, USA 01581jtc@motcad.portal.com (J.T. Conklin) (04/27/91)
In article <2731@spim.mips.COM> mash@mips.com (John Mashey) writes: >I think Jay and J.T. are talking about different levels of things, >and since ACE was mentioned as the start of this, let me explain exactly >what is and isn't going on. You're right. I missed the fact that Jay was talking about a specification which would enable an operating system to run on two different vendors' hardware platform. This would be nice (especially when its time to port GNU OS to the 88k) but right now I am content with the ability to build binaries that can run on any 88open machine. But that doesn't mean I wouldn't like to run DG/UX on a Motorola MPC! -- J.T. Conklin jtc@motcad.portal.com, ...!portal!motcad!jtc
jay@metran.UUCP (Jay Ts) (04/28/91)
[my post has generated a flurry of lengthy and intelligent email replies, and all of them so far have been deservant of a similar response from me. For all those who sent me email, please understand that I am not ignoring you, it's just that I have limited time. It's a minor fan-out problem.] I am not sure what sort of tone will be read into any of this by the reader, so at least let me say that I am not intending to be argumentative; I just want to explain myself. In article <1339@dg.dg.com>, quirk@quokka.rtp.dg.com (Peter Quirk) writes: > I think that Jay has misinterpreted the intentions of the 88open, > and grossly underestimated the size of the task involved in > producing a Shrink-wrapped UNIX for 88K systems that would serve > the great bulk of users. I have been following 88open with varying levels of interest since the 88k was announced. I understand that the main intention from the start was to create a shrink-wrap applications software environment, but it's just recently that I've been made fully aware that the hardware side was let go. I never said that a hardware standard would be easy, just worthwhile. > What sets the 88K apart from the other architectures is: > 5. a binary compatibility standard based on international and de facto > standards. Exists on MS-DOS, PC UNIX, and is under development by SPARC International. > 1. a highly scalable multiprocessor architecture Also included in the design of the 486. SPARC International is coming out with theirs soon, and so are the MIPS people. The 88k was first, and the multiprocessor support was designed in from the start, but you can bet that the SPARC and MIPS people have been leafing through the 88000 User Manuals on occasion looking for ideas. > 2. the lack of an I/O bus standard Well, I would put that under the tablecloth and hope no one noticed! :-) Seriously, I get your point (it allows versatility), but it also has major limitations for third-party hardware vendors. Even if there were an agreed-on standard, the 88k vendors would be able to use whatever bus they needed; that particular system wouldn't pass certification, but in that case, the vendor would use a nonstandard bus to overcome a limitation of the standard one, and would be able to sell it to the customer as a feature. Just make sure the extra performance, versatility or whatever is valuable enough to the customers to overcome the added complications to them. This issue would of course apply to the entire hardware standard, not just the bus. I am going to use a car analogy to try to bring this discussion down to earth. First, let me say that I am not trying to make every car manufacturer in the world produce nothing but Ford Escorts. I am thinking in terms of parts. When you go to the auto store to get spark plugs for your car, you don't want to have to get a specific plug that only works on your car and no one else's. In that case, you would have to go to the parts department at your dealer, and pay astronomical prices for them. (Case in point: Data General charges $9000 for a 320 Mb SCSI drive. It's an OEM'd Micropolis drive, which I can get mailorder for about $2000. Before I'm taken wrong, I think it is *excellent* that Data General will allow a customer to just go out and buy and install their own Micropolis drive, and will even support it afterwards!) Now, there isn't just one "industry standard" spark plug. There are a few types. Well, there are a number of them, actually, and each has its own advantages for the design in which it's being used. But the number is small enough that no matter what kind of car I have, I can feel confident that I can get the plugs at a local store for a good price. Contrast this to the current situation with headlights. Remember when a headlight burned out, you could go to an auto store, and get a replacement for $10-15? Not any more! The fashionable new "euro aero" headlights now go for $130-150, available direct from your dealer. What happened? Well, the auto manufacturers found that they could save about 1% on aerodynamic efficiency by modifying the headlights to fit into the nose smoothly, so when the government deregulated them, they all went out and developed incompatible "advanced" headlights. Am I getting through to you people yet? Are you looking forward to spending $300 to replace your car's headlamps for 1% extra aerodynamic efficiency? My point is this: I don't want to slow the wheels of progress, but neither do I want to be run over by them because someone had to make things just a little bit better. Not every technological advancement works for the benefit of humanity as a whole. > 4. a working certification process for binary compatibility. I have been informed that SPARC International also has that. Also, on the PC, I have my own "working certification process" (for both hardware and software). I call the vendor and ask if it works. (Then maybe I'll call some other people and ask them, too...) If I install the product and it doesn't work, it goes back to the distributor in return for another alternative. The market is so big that there are a number of choices, and a number of distributors that will work on those terms. As I said before, de facto Open Systems. > Now if you insist that 88open is backward in providing a standard HW > interface so that software vendors can produce shrik-wrap UNIX operating > systems for all 88K systems I would simply observe the following: > > 1. The presence of a perceived open HW standard in the PC has not > resulted in any significant operating system offerings apart from > DOS (DrDOS included). I hate to think that I could even come up with a list of all the operating systems available for the PC. MS-DOS, UNIX (from a *number* of vendors, including Interactive (the oldest commercial Unix vendor), SCO (not far behind), ESIX, Dell, UHC), Xenix, BSD UNIX, OS/2, Coherent, PC-MOS, TurboDOS, Concurrent DOS, etc., etc., etc. I don't know what you mean by "significant", but keep in mind that Xenix accounts for a *very* large share of installed UNIX systems worldwide; it is the plurality if not the majority. > 2. The market for alternative, totally compatible, operating systems > on anyone's box is minimal. See above. I'm sure glad SCO isn't the only vendor, and that goes for ISC as well. Thank goodness for ESIX, who have added two "enhancements" to their product that have been in need in the PC UNIX market: free technical support and low price. Dell is also getting good marks in comp.unix.sysv386 for it's advanced, bug-free code. I don't care if the market is "minimal", just so long as it's there! It takes alternatives such as these to keep SCO and ISC focussed on improvement. Jay Ts, Director Metran Technology uunet!pdn!tscs!metran!jay
guy@auspex.auspex.com (Guy Harris) (04/28/91)
> SPARC huge open hardware and software; > formal standard - SPARC International Really? I know of no formal standard for "SPARCstation-like" hardware, from SI or from anybody else. In fact, whilst Sun's machines, as of now, use Sun-style MMUs, many of the clones use SPARC Reference MMU implementations, and those don't look all that much like Sun-style MMUs. (In addition, not all SPARC Reference MMUs are identical; the Reference MMU spec nails some stuff down, but not everything.) In addition, not all of the J. Random peripheral registers are necessarily the same, although I suspect most clones use many of the same peripheral chips. On top of that, of course, not all SPARC machines are workstations; one can't get much less compatible with the SS1's frame buffer than not to *have* a frame buffer....
jay@metran.UUCP (Jay Ts) (04/28/91)
In article <1991Apr27.042206.24232@motcad.portal.com>, jtc@motcad.portal.com (J.T. Conklin) writes: > In article <2731@spim.mips.COM> mash@mips.com (John Mashey) writes: > >I think Jay and J.T. are talking about different levels of things, > > You're right. > This would be nice (especially when its time to port GNU OS to the 88k > > But that doesn't mean I wouldn't like to run DG/UX on a Motorola MPC! That's a good point! In my 10 days of evaluating an Aviion workstation, I became very impressed with DG/UX. I only had it for 10 days, but for the level of analysis I was able to do, it seems like a very good system. I was surprised to find out that Data General sells the UNIX license separately from the hardware, and for only $450! That seems too incredible to be true... someone pinch me. If they could do this as a hardware independent product, then a competitor's customer would have the choice of buying DG/UX as a replacement for the native UNIX port. Certainly, you would think that Data General itself has a lot to gain from a hardware standard. Jay Ts, Director Metran Technology uunet!pdn!tscs!metran!jay
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (04/30/91)
In <16@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: > PC-compatibles massive open hardware and software; > "de facto" industry standard. "standard", HA! Why do you think all of the software vendors have to ship video drivers for every card with their programs? There is a sort-of standard ISA, "plain" VGA, but it's so lame that most customers WILL NOT use it. And the card vendors ship drivers for some programs, like Windows, so people will be able to use them. > SPARC huge open hardware and software; > formal standard - SPARC International Some standard. I can use VME, S-bus, or ... How do I write a shrink-wrap kernel for that? Not to mention the FP and MM variations. The last thing I want is a hardware standard. Why use the results of a committee working in 1991 to limit your hardware potential in 1995? How do you deal with improved cache architectures, faster/wider buses, or interfaces that haven't even been invented yet? A binary standard is necessary, these days. A presentation standard, or two (OpenLook and Motif, for example) will be soon, if it isn't already. Media compatibility is also necessary. These standards allow software vendors, the (IMHO) real driving force in our industry to create and package their products, and support them, at a cost-competitive level. After all, no matter how good (or bad) a computer is, it's the software that does the customer's useful work. A hardware standard removes the only place that the "iron" vendors can differentiate their products. Who needs that. NOT me!!!! The day an 88K hardware standard exists, is the day the 88K dies. Dan Taylor /* My opinions, not NCR's. */