chris@mimsy.UUCP (Chris Torek) (07/30/88)
In article <3395@vpk4.UUCP> scott@attcan.UUCP (Scott MacQuarrie) responds to the line: >>It is only the greed of the corporate environment that makes ATT want to >>have anything to do with UNIX .... with a number of reasonable and largely accurate (if somewhat slanted) points. Nonetheless, were it not for `greed' (you may tone this down to `a desire to be paid well for a job well done' if you wish), few if any corporations would even exist. In this particular sense (`greed' as a foundation for capitalism, as `honesty' is a foundation for socialism, which tells you why capitalism works more often :-/ [this is a `wry smile' face]), `greed' is not, or not wholly, negative. Indeed, sufficently-enlightened greed is quite healthy. >When was the last time you saw a major computer vendor give source to any >of its products to anyone! I think the only reason AT&T sells source licenses is historical: - When Unix licensing began, AT&T could not sell software, nor were there any solid portents of the divestiture. Hence there was no reason *not* to; when Thompson et al. asked, a `yes' was more or less as easy as a `no', and had some beneficial side effects. - Now that Unix(TM)(R)(C)(Pat.Pend.)(K)(U) is a product, it is apparent to some/many that a large part of Unix's desirability stems from familiarity. Unix has technical merits, yes; but it also obvious that, had Bell Labs never distributed versions of Unix, few would know of it, and few would push those merits hard enough to convince the people who hold the purse-strings. As it is, college graduates---who make up the largest group of programmers entering the marketplace---are often familiar with Unix, and will therefore ask for it. Since so much Unix software is portable, and these people know it and can demonstrate it, Unix may win out over a technically superior O/S for a particular application simply because most of the needed software already exists. - It is to AT&Ts advantage, at present, to have Unix ported to larger computers (Alliant, Encore, Cray): it gives more support to their position of supplanting IBM: `use our machines and you can retain your old software when you need to expand.' Finally, although it is a minor point: - The mechanisms for source distribution are already in place. Enlightened greed says that selling source licenses is working. I suspect that if other vendors were in a similar position, they would act similarly. The reasons you cannot get VMS or MVS sources are also more historical than anything else. [Incidentally, you *can* get sources from IBM in some cases, but what you get may not be what you expected.] As vendors go, AT&T is neither the valiant knight in shining armour, saving us from the evil fate of machine-dependency, nor is it the villain in black, tying us to the railroad tracks as the train tootles towards us. It is simply a corporation, doing what corporations do, and (luckily for us) enlightened as to the effects of selling source. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
friedl@vsi.UUCP (Stephen J. Friedl) (07/31/88)
In article <12755@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > Unix may win out over a technically superior O/S for a particular > application simply because most of the needed software already > exists. Wow, I've never heard *that* about UNIX before :-). One of the largest complaints about UNIX is that application software is *not* available. We've got compilers but not (say) grocery store accounting systems, and there are many more of "them" then there are of "us". -- Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl --------- Nancy Reagan on flood-control: "Just say Noah"-----------
chris@mimsy.UUCP (Chris Torek) (07/31/88)
>In article <12755@mimsy.UUCP> I wrote >>... Unix may win out over a technically superior O/S for a particular >>application simply because most of the needed software already exists. In article <766@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) answers: >Wow, I've never heard *that* about UNIX before :-). Simply because there *are* no superiour [what spelling consistency?] O/Ses. (Yet.) :-) >One of the largest complaints about UNIX is that application >software is *not* available. We've got compilers but not (say) >grocery store accounting systems, and there are many more of >"them" then there are of "us". I was thinking more along the lines of data gathering and analysis for, say, an insect neurology lab. (Much of this tends to run under real-time constraints; it might in fact be cheaper to buy an O/S with RT data gathering already supported than to hack the V7 scheduler.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
tab@mhuxu.UUCP (Tracey Baker) (08/01/88)
In <766@vsi.UUCP>, friedl@vsi.UUCP (Stephen J. Friedl) wrote: >One of the largest complaints about UNIX is that application >software is *not* available. We've got compilers but not (say) >grocery store accounting systems, and there are many more of >"them" then there are of "us". I just read an interesting article in the latest (August 1988) UnixWorld entitled "Success Stories". It gives quick overviews of about 15 places where software running under UNIX is being used to solve some interesting problems. From the beginning of the article: That old saw about how "there's no software under UNIX" is finally obsolete. According to the /usr/group's _1988 UNIX Products Directory_, there are almost 300 accounting software packages, 84 graphics packages, 133 office automation packages, 84 word processing/text formatting packages, 74 medical/dental programs, and 202 manufacturing and distribution packages, to name a few. UNIX solves problems both large and small. The article goes on to describe a graphics package being used to design lingerie, a computer-aided neurosurgery monitoring system, flight simulators for the Air Force, and many other UNIX applications outside of the "traditional" UNIX environments. Sounds to me like the vendors are finally starting to listen to "them". -- Tracey Baker {att, rutgers!moss}!mhuxu!tab or tab@mhuxu.att.com (201)582-5357 Rm. 2F-211, AT&T Bell Laboratories, 600 Mountain Ave., Murray Hill NJ 07974 Any resemblance to actual opinions, |"There ain't no cure when the rabid living or dead, is entirely coincidental. | rock dog bites..." - Split Sydney
Dion_L_Johnson@cup.portal.com (08/04/88)
Steve Friedl said:
--In article <12755@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
--> Unix may win out over a technically superior O/S for a particular
--> application simply because most of the needed software already
--> exists.
--Wow, I've never heard *that* about UNIX before :-).
--One of the largest complaints about UNIX is that application
--software is *not* available. We've got compilers but not (say)
--grocery store accounting systems, and there are many more of
--"them" then there are of "us".
----
--Steve Friedl V-Systems, Inc. +1 714 545 6442 3B2-kind-of-guy
--friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
Right now being printed is the new edition of the SCO XENIX System V
Directory - a (more or less) typical catalog of systems and
application programs, hardware, services, consulting, etc.
for the SCO XENIX environment. There are
over 1800 software packages including about 80 pages of listings of
accounting packages (it's the largest category). Watch for an
official announcement of this book in a few weeks. You'll be amazed
at the range of commercial (and other) packages available.
Dion L. Johnson
(in real life: dionj@sco.com. Disclaimer: Doug made me say it)rml@hpfcdc.HP.COM (Bob Lenk) (08/11/88)
> I disagree. It is much easier to write portable software in SVID > than it is to do it in POSIX. POSIX left too many features optional > and implementation dependent. I've heard that a lot, but I have yet to see evidence that it's true. Yes, the words "option" and "implementation defined" appear much more in POSIX than in the SVID. Conversely, the SVID has various "extensions" which are the same as "options". Also, I think that the greatest number of "implementation defined" areas are areas that the SVID simply ignores. Now, let's go through the explicit options in POSIX Draft 12.3 (since they're fairly easy to find) and see how POSIX and SVID compare as portability aids: NGROUPS_MAX (BSD multiple groups) SVID effectively has this limit set to zero, meaning that it omits a feature. It's straightforward to program portably for any value of this limit. Admittedly it's not quite as simple as programming for a system without the feature, but the additional sophistication should be no problem for the type of application that would be interested. Of course various SVID-conformant system provide ways to get this BSD functionality in some type of non-SVID environment; the SVID-based application just has no way to deal with this. _POSIX_JOB_CONTROL SVID simply doesn't provide the feature. A POSIX application that wants to be job control dumb is similarly unaffected. _POSIX_SAVED_IDS (SVID saved-set-user/group ID feature) This is a case where SVID simply does provide the feature. That does make programming easier (it would also help if SVID and the SysV implementation agreed). _POSIX_CHOWN_RESTRICTED (can non-superuser chown files?) SVID permits arbitrary chown'ing, which does make portable programming easier. On the other hand, too many people think this is a severe security hole to accept it. As a result, there are vendors whose systems conform to SVID except for this (and perhaps one or two other small things). Thus portability is eased in a smaller universe. In reality, a portable program that simply doesn't use chown (under the assumption that it might not work) is no problem to write. _POSIX_NO_TRUNC (is too long filename truncated or does it give error?) This is a rather messy situation to deal with in POSIX. SVID is totally silent on the semantics here. The diversity thus exists there too, but the application has no handle on it at all (as opposed to a clumsy handle in POSIX). _POSIX_VDISABLE (is there a setting to disable special tty characters?) SVID takes the side that there is no such special character. This makes portable programming simpler in two cases: (1) where the application wants to set the special character (eg. ERASE) to some bizarre value (like '\377') that the system chose as the disable value, and (2) where the application wants to emulate the line discipline. Conversely, it does not allow disabling the special character function. I'll also look at two of the most commonly mentioned explicit options from Draft 12, which are now implicit in 12.3 (note that a number of others are no longer options, either explicit or implicit): _POSIX_DIR_DOTS (are the . and .. entries visible via readdir()?) SVID is totally silent on the semantics here. An application can easily be written to ignore these entries if it sees them. POSIX explains this. _POSIX_GROUP_PARENT (is new file's group from eff. uid of creating process or group ID of parent directory?) SVID goes with the effective uid, making things more predictable. A portable POSIX program can always get these semantics by chown'ing the new file after creation, which is a little more work, if it cares. In conclusion, I don't see that the SVID makes life all that much easier, or that the POSIX options are without justification. There's a separate argument that SVID covers more. That's very true if you compare it to 1003.1. I doubt it will be true in comparison to the standards eventually covered by the 1003.0 guide. SVID certainly has a head start, and is very useful because of that. Its existence is very useful for the development of 1003.1 and other standards. But SVID is a different animal than POSIX. SVID is a specification of the interface to a specific operating system. While it can be applied both to ports of that system and to separate implementations conforming to the same interface, its heritage is definitely a single implementation. As such, one would expect it to permit less divergence, and to apply to fewer implementations. Apologies for the length of this posting. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com
donn@hpfcdc.HP.COM (Donn Terry) (08/12/88)
There has been a series of postings on this topic all with the theme that "somebody has to make UNIX(TM) 'right'". The "somebody" isn't a single *vendor*, nor is it the standards bodies, but rather the marketplace. The existence of standards (such as POSIX) makes it reasonably possible for buyers to specify what they want in a vendor independent fashion. (Just like nuts and bolts.) They then can choose based on price, additional features, whim, or whatever else they like between the systems meeting that standard. More importantly, if the standard isn't what they want, they can tighten up the specification. They can also add to it, or even change it. In doing so they take a risk of having no vendor meet the specification, or a higher price, or delays, but it's the buyer's risk, and if its valuable enough to him, he'll take it. A purchaser like the Federal Government (in the form of a FIPS) has done exactly that with the POSIX FIPS. It's tighter than IEEE's POSIX standard, and the size of that market will draw most vendors to comply with the FIPS (and thus with IEEE's version). You want compliance to a standard: you'll have it within probably a year from most vendors, and it was done by free-market means, not via contractual enforcement or other coercion. (A vendor doesn't have to comply with the FIPS; it just might want to however; the income is nice.) A proprietary specification could, theoretically, have had the same effect. The several attempts I know of have not had that effect. One of the reasons is that because they weren't created by an open process and weren't (perceived of(!!)) as reasonably independent of the owner's whim, and thus competitors weren't that interested in follwing the specification, possibly to their own disadvantage. More importantly, those specifications do not appear to me to be technically attractive enough to overcome this problem. Had they been, they might have succeeded in spite of the above problem. In the case of OSF: there is a baseline specification that they will deliver (read the literature). It's not really well defined yet, but that should happen. If that specification matches buyer's needs, what OSF has will sell. If it doesn't, OSF goes out of business. In this case, the direct buyers are the vendors of systems. If OSF's specificaitons meet the vendors' customers' needs, the vendors will buy it and pass it thru, adding what's missing for their particular customer base. If not, the vendors will solve the problem some other way. The folks at OSF aren't stupid, and they realize this. To the extent that existing specifications match the marketplace, they'll adopt them. The best way, in my opinion, to assure the success of the proprietary standards (to the demise of today's leading open standard, the UNIX System) is to try to legislate the "right" answer, rather than letting the customers decide in a free market what they want. Please don't delude yourself into thinking that somehow, magically, you know what the customers want. You, at best, understand *what you heard* from those customers you talked to. That may be a factor, but I've seen many a product be of more value to an unintended marketplace than for the target market for which it was designed. (I think UNIX's target market was originally amateur astronomers, at least according to one story I heard.) Donn Terry HP Ft. Collins My comments represent only my own opinions, that of my employer or anyone else.
henry@utzoo.uucp (Henry Spencer) (08/20/88)
In article <5980026@hpfcdc.HP.COM> rml@hpfcdc.HP.COM (Bob Lenk) writes: >Yes, the words "option" and "implementation defined" appear much more >in POSIX than in the SVID... It is worth noting, mind you, that a number of the POSIX gray areas -- last time I saw them -- were exactly the sort of things that no sensible programmer makes his program depend on anyway. Who *cares* whether "." and ".." show up when you examine a directory?!? You're only going to ignore them anyway. -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu