Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.vbc.net!garlic.com!news.scruz.net!kithrup.com!news.Stanford.EDU!bloom-beacon.mit.edu!news.mathworks.com!uunet!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc
Subject: Re: TCP latency
Date: Mon, 15 Jul 1996 18:16:06 -0700
Organization: Me
Lines: 160
Message-ID: <31EAED56.84E039@lambert.org>
References: <4paedl$4bm@engnews2.eng.sun.com> <4rrimn$dro@fido.asd.sgi.com> <4sc2lk$d3l@uriah.heep.sax.de> <4seep0$f0l@fido.asd.sgi.com>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.advocacy:55513 comp.unix.bsd.freebsd.misc:23684
Larry McVoy wrote:
] Actually, it's not distributuions that I care about, it's kernel level
] source trees. The Unix world has fragmented to the point that there
] are several standards bodies that do nothing but try (unsuccessfully)
] to hold it all together.
This may be the intent of standards bodies, but it is not their
intention... the distinction is subtle.
The purpose of a standards body is to raise the bar for a
competitor by getting what you have already implemented
standardized in trade for getting what your competitor has
already implemented standardized, with the implied bet that
you can recreate his work before he can recreate yours.
This is standardization at its best.
At its worst, standardization is a means of implementing a
private club, where each club member pays dues in the form
of a technology buy-in (or "baseball trading card"). Motif
is a good example: Motif is a ratified standard, even though
there are no public reference imlmenetations.
] Step back and look at Unix from Microsoft's perspective, or
] the customer's perspective. We look like a bunch of
] squabbling kids - this thread is a great example. If Unix,
] say 5 years ago, had converged to one source base, to the
] point that the default installation on every hardware
] platform was identical (same apps, same window manager, same
] look and feel, same system calls), then Unix would have stood
] a chance of being the Windows/NT of today. As it stands, the
] customers hate Unix, and are doing everything they can to
] migrate off of it.
Or, say, 3 years ago when Sun bought out their license for $80M
and could put the SVR4 sources up under GPL or UCB license for
anonymous FTP, instantly commoditizing the UNIX market? 8-).
[ ... ]
I'm going to agree to disagree with you on the "Linux vs. BSD"
positioning. I think you have some history here which causes
you to be biased, and I'll leave it at that.
If you really feel that defragmentation will help, I've already
suggested (Message-ID's: <31734160.1332595A@lambert.org>,
<31759D8B.59F3653A@lambert.org>) that the real way to play the
game and win would be to defragment the application space:
| Typical UNIX "infighting":
|
| 1) Adopt a proprietary standard. Hope your competitors
| can't afford the buy-in.
|
| 2) Adopt a non-proprietary standard. Define "extensions",
| and make it necessary to use them so that products
| compiled for your platform won't run on someone elses,
| but products compiled for someone elses will run on yours.
|
| 3) Adopt a non-proprietary standard. Make the certification
| process proprietary. Hope your competitors can't afford
| the buy-in (ie: "Linux is certified POSIX compliant").
|
| 4) Adopt a standard. Include expensive baggage. Hope
| the baggage is an impediment to compliance (ie: hope
| your competitors can't afford the buy-in). Spec1170,
| UNIX95.
|
| 5) Adopt a competing standard. Hope your standard wins
| (ie: SVID vs. DEC Ultrix and SCO Xenix).
|
|
| 6) Adopt a standard that you are architecturally better
| suited for than your competitor (aka the Oracle SQL
| extension standard), and hpe they can't compete when
| they toe the arbitrary division line you've set.
[ ... ]
| The best answer is that ABI emulation is a disadvantage in the
| race to get native ABI products.
|
| If FreeBSD supports the Linux ABI, what is the incentive to
| make a native FreeBSD port?
|
| If there is not an ABI ceritification process and developement
| tools to insure conformance, then the vendors will not
| subsequently offer support for the product when it is run in
| the emulation environment.
|
| This has already caused there to be no FreeBSD "Netscape" release,
| since it can run both the "Linux" and "BSDI" versions, Netscape
| sees no reason to provide a native port.
|
| The Linux ABI version is unsupported anyway, but the BSDI version
| is preferentially unsupported when running in the BSDI ABI
| environment because the certification process caused the binary
| to be ceritified to run under BSDI, not under the BSDI ABI.
|
|
| One big win would be a written ABI specification, a *publically
| available* test suite to make sure a system implements the ABI
| from revision to revision, and a mode switch for each compliant
| system to place it in "ABI ONLY mode" to determine application
| conformance to the ABI.
|
| The system vendors would have to encourage the use of this mode
| when running testing on commercial products by offering both
| self-ceritification (branding: "Free UNIX Friendly"?) and by
| only guaranteeing the interfaces exported by the ABI from
| revision to revision. If a commercial vendor wants to avoid
| another port for the next OS release, they need to certify.
|
|
| I would suggest the EABI (Motorolla version), a publically
| available ABI specification, only the Linux ELF is already
| non-compliant with it (several fixes needed), and the standards
| compliance body is already self-selected -- they have a test
| suite, it isn't *publically available*, and certification and
| trademarking already exist.
|
| Otherwise, it's perfect, in that sufficient momentum could
| unify the already fragmented i386 commercial UNIXes as well.
|
|
| I wonder what it would take to get the suite released and
| for the vendors -- SCO, Novell, Sun -- to implement an "ABI
| only" mode to prohibit some of the infighting techniques
| outlined above?
[ ... call to action ... ]
| Free
| Application
| Binary
| Interface
| Objective
|
| project ...or Project FABIO, for short.
|
|
| Donations of SVID/SVR4 ABI/EABI test suites for the TET/ETET
| compliance testing framework gratefully accepted for cut-down
| to limit them to public technology standards.
|
| Commercial vendors: note that donation of a test suite would
| go a long ways toward ensuring that your commercial implementation
| would be FABIO compliant, since it's harder to fail a test suite
| that already runs on your platform, even if it has been cut-down
| to exclude all proprietary technologies that require a buy-in for
| their use.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.