news@spies.UUCP (07/26/88)
Well, boys and girls, according to today's Computer World, ATT has decided to join OSF!! They are submitting Open Look as OSFix's interface standard, replying to the OSF RFP. Waddya think? Does this mean a still more radical revision of Sys V rev 4's licensing terms? Us Inquiring Minds want to know! ee
ehrlich@blitz (Dan Ehrlich) (07/27/88)
In article <347@spies.UUCP> writes: >Well, boys and girls, according to today's Computer World, ATT has decided Gee wiz, what is the issue number? Or, maybe the date? I assume that the world is still working on volume XXII like me. :-) Dan Ehrlich <ehrlich@blitz.cs.psu.edu> | Disclaimer: The opinions expressed are The Pennsylvania State University | my own, and should not be attributed Department of Computer Science | to anyone else, living or dead. University Park, PA 16802 |
rogers@ofc.Columbia.NCR.COM (H. L. Rogers) (07/27/88)
In article <347@spies.UUCP> writes: >Well, boys and girls, according to today's Computer World, ATT has decided >to join OSF!! They are submitting Open Look as OSFix's interface standard, >replying to the OSF RFP. Waddya think? Does this mean a still more >radical revision of Sys V rev 4's licensing terms? > >Us Inquiring Minds want to know! With all due respect to those of you who wear the blue suits (as in Big Blue), I hope this means the development base for "OSFix" becomes SVR4 instead of AIX. AIX may be a great implementation, but its performance metrics leave a bit to be desired. Does AT&T membership give respectability to the OSF crowd? -- HL Rogers (hl.rogers@ncrcae.Columbia.NCR.COM)
ekrell@hector.UUCP (Eduardo Krell) (07/27/88)
In article <347@spies.UUCP> e_e_cummings@fatcat.UUCP writes: >Well, boys and girls, according to today's Computer World, ATT has decided >to join OSF!! They are submitting Open Look as OSFix's interface standard, >replying to the OSF RFP. Waddya think? I think there's a big difference between joining OSF and responding to the user interface RFP. AT&T/Sun are trying to push Open Look as a standard, and having it adopted by OSF would be a step in that direction. If anything, it would mean more problems with the OSF license, as OSF would have to license Open Look from AT&T. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
dougm@ico.ISC.COM (Doug McCallum) (07/27/88)
In article <347@spies.UUCP> writes: >Well, boys and girls, according to today's Computer World, ATT has decided >to join OSF!! They are submitting Open Look as OSFix's interface standard, >replying to the OSF RFP. Waddya think? Does this mean a still more >radical revision of Sys V rev 4's licensing terms? I think it means you didn't read the article very carefully. All it says is that they are considering submitting Open Look and that they might consider joining OSF if no obstacles got in the way. Other than that it doesn't mean much.
keith@hpcvlx.HP.COM (Keith Taylor) (07/27/88)
>Well, boys and girls, according to today's Computer World, ATT has decided >to join OSF!! They are submitting Open Look as OSFix's interface standard, >replying to the OSF RFP. OSF's RFP is open to companies outside of OSF. AT&T can submit Open Look without becoming a member.
vandys@hpisoa1.HP.COM (Andrew Valencia) (07/27/88)
/ hpisoa1:comp.unix.wizards / rogers@ofc.Columbia.NCR.COM (H. L. Rogers) / 10:19 am Jul 26, 1988 / >...I hope this means the development base for "OSFix" >becomes SVR4 instead of AIX. AIX may be a great implementation, >but its performance metrics leave a bit to be desired. I'm no IBM'er (and if you saw me, you'd probably bet I'll never be! :->), but it isn't fair to make comments about the performance which OSF's AIX will deliver. It is "supposed" to be a significant rework of AIX. Until we have seen the actual OSF AIX, it just isn't fair to make comments about its performance. Andy Valencia In case you hadn't noticed, these are *my* opinions, not HP's.
kluft@hpcupt1.HP.COM (Ian Kluft) (07/28/88)
rogers@ofc.Columbia.NCR.COM (H. L. Rogers) writes: > Does AT&T membership give respectability to the OSF crowd? Actually, it was AT&T and Sun who were lacking in respectability after trying to steal the whole market for themselves. (Disclaimer: Official HP statements only come from HQ in Palo Alto.) ------------------------------------------------------------------ Ian Kluft RAS Lab UUCP: hplabs!hprasor!kluft HP Systems Technology Division ARPA: kluft@hpda.hp.com Cupertino, CA ------------------------------------------------------------------
bzs@bu-cs.BU.EDU (Barry Shein) (07/28/88)
From: kluft@hpcupt1.HP.COM (Ian Kluft) >rogers@ofc.Columbia.NCR.COM (H. L. Rogers) writes: >> Does AT&T membership give respectability to the OSF crowd? > >Actually, it was AT&T and Sun who were lacking in respectability after >trying to steal the whole market for themselves. "Steal" is a very strange choice of words to apply to the owner (AT&T). Mayhaps the pot calls the kettle black? Nah, I'm sure the OSF members were only trying to reassert their firm commitment to the rights of software owners... Anyone want to join me in forming the CLOSED SOFTWARE FOUNDATION? (a subsidiary of my EMPEROR'S NEW SOFTWARE FOUNDATION.) We can talk about how we're going to enforce industry standards on VMS, MVS, CMS, AEGIS, etc, all those things that end in S instead of X. Then we can accuse them of STEALING the market! Ah well, it's not suprising to see this all break down to Sunday afternoon sports-bar-babble. -Barry Shein, Boston University
kramerj@beasley.CS.ORST.EDU (Jack Kramer - OSU Gene Res) (07/28/88)
In article <5960008@hpcupt1.HP.COM> kluft@hpcupt1.HP.COM (Ian Kluft) writes: >rogers@ofc.Columbia.NCR.COM (H. L. Rogers) writes: >> Does AT&T membership give respectability to the OSF crowd? > >Actually, it was AT&T and Sun who were lacking in respectability after >trying to steal the whole market for themselves. > >(Disclaimer: Official HP statements only come from HQ in Palo Alto.) >------------------------------------------------------------------ AT&T and Sun trying to steal UNIX? How much did OSF members such as IBM, DEC and Apollo spend over the last 15 years to get UNIX where it is today? But I guess UNIX does need to be brought up to date. When will we be able to get the new JCL manuals that will finally make UNIX as easy to use as IBM's other OS's? Have you tried to get a copy of MVS source from DEC - their openness will certainly add to the continued development of the "new" UNIX. The list of potential benefits that the proprietary money mongers will introduce is unlimited.
cricket@hp-sde.SDE.HP.COM (Cricket Liu) (07/29/88)
/ hp-sde:comp.unix.wizards / kluft@hpcupt1.HP.COM (Ian Cluft) / 2:04 pm Jul 27, 1988 /
> (Disclaimer: Official HP statements only come from HQ in Palo Alto.)
And even then, they're only official when we say they are. :)
Cricket (not speaking ex cathedra today, thank you very much) Liu
Hewlett-Packard Integrated Office Systems
ARPA: cricket%hpiosa@hp-sde.sde.hp.com
UUCP: hplabs!hpiosa!cricketvandys@hpisoa1.HP.COM (Andrew Valencia) (07/29/88)
/ hpisoa1:comp.unix.wizards / kramerj@beasley.CS.ORST.EDU (Jack Kramer - OSU Gene Res) / 8:59 am Jul 28, 1988 / >Have you tried to get a copy of MVS ^^^ >source from DEC - their openness will certainly add to the continued ^^^ >development of the "new" UNIX. Gave me a chuckle. I can just imagine the expression on the DEC account rep's face for this request!
benoni@ssc-vax.UUCP (Charles L Ditzel) (07/30/88)
in article <2200021@hpisoa1.HP.COM>, vandys@hpisoa1.HP.COM (Andrew Valencia) says: > I'm no IBM'er (and if you saw me, you'd probably bet I'll never be! :->), > but it isn't fair to make comments about the performance which OSF's AIX > will deliver. It is "supposed" to be a significant rework of AIX. Until > we have seen the actual OSF AIX, it just isn't fair to make comments about > its performance. Spare me. It is as appropriate to make comments about OSF's AIX as it is to be gullible enough to believe the OSF's event marketing. It's vapor ware and if it's anything like the AIX i tried a few weeks back then i think the comments his comments were appropriate ... ---------------- Naturally my opinions are not HP's, Apollo's, DEC's, IBM's or my employers.
scott@dtscp1.UUCP (Scott Barman) (07/30/88)
Before I begin, I am not commenting on Mr. Kramer's posting itself. I am just using it as a platform to comment on the state of Unix in general. Also note: I have been trying to get this posted for a few weeks now, but some problems prevented it! :-) In article <5796@orstcs.CS.ORST.EDU>, kramerj@beasley.CS.ORST.EDU (Jack Kramer - OSU Gene Res) writes: > In article <5960008@hpcupt1.HP.COM> kluft@hpcupt1.HP.COM (Ian Kluft) writes: > >rogers@ofc.Columbia.NCR.COM (H. L. Rogers) writes: > >> Does AT&T membership give respectability to the OSF crowd? > > > >Actually, it was AT&T and Sun who were lacking in respectability after > >trying to steal the whole market for themselves. > > > AT&T and Sun trying to steal UNIX? How much did OSF members such as IBM, > DEC and Apollo spend over the last 15 years to get UNIX where it is > today? But I guess UNIX does need to be brought up to date. When will And how much has AT&T (not the Bell Labs people) done to Unix over the last 15 years? Up until five or six years ago, NOTHING! Then, when they decided that they wanted to make it a *real* product, they took the thing and bastardized it sooooo much that I remember the times I cursed AT&T up the ioctl system call and down utmp structure while porting software from The Seventh Edition of Unix to System V Release 2. And it continues! Unix, as it stands today, has problems since it does not seem that (maybe up until now) AT&T has ever had a real direction for its growth. It is inflicted with a disease called "creeping featurism" where the simplicity of Unix tools have been mucked with more junk then they need (don't laugh you BSD people, 4.[23]bsd just wreaks with this problem as well). And the kernel?! Why must everything be burried in the kernel? Why must we have kernels with text regions of over 256K? Why must we have facilites that do not conform with Unix's original idea of accessing them as a file (see sockets, semaphores, message queues, etc.)? And why must confusing and nonsensical functionality be added where it is really not needed (see System V's init)? Enough already! The original appeal of Unix was how simple ideas can be put together in a simple, logical manner to produce the desired results. Tools were created to do simple tasks. With these tools we were able to accomplish most goals and the ones we could not accomplish, we just wrote another tool to do the work. Now we have programs that will reformat our source files putting tabs, etc. in the right places, shells with half the world built into them, and two different versions of a screen handling package for dumb tubes that are not compatible with each other (no comments here on windowing packages since they are too new and and "standards" have really not been set). And there is more to come! With AT&T and Sun *playing* with Unix, no doubt there will be an extension to all programs--more creeping featurisms--that will give us things like a pr that will do everything but load the paper for you and system calls for virtual memory mechanisms that should be hidden from the general user anyway. I am not forgetting about the OSF people whose chief supporters, IBM and DEC, have not written "small" system since they were limited to 64K of memeory. (Isn't Open Software Foundation an oxymoron when mentioned in the same sentence with IBM and DEC?) When will it end? HA! Never, probably, since everyone wants to keep adding more and more to it. Maybe it will buckle under its own weight, I don't know. But I think that if Unix is to survive it needs a mass cleanup to go *back* to its original idea of "small is beautiful" and get some of the junk out of it (e.g. if you have streams, then why is there a tty "driver", see Dennis Ritchie's paper for better explanations). If this doesn't happen I see Unix running into the same memory and storage problems that is going to doom OS/2. I can only hope that those involved will hear this lonely voice in the crowd (probably a minority opinion) and just consider the consequeces as Unix grows to consume all available resources. I will get off my soapbox now and begin to line the mailbox with asbestos (again) since I can hear them flames-a-commin'! :-) -- scott barman ..!gatech!dtscp1!scott Digital Transmissions Systems, Inc. Duluth, Georgia
richt@breakpoint.ksr.com (Rich Title) (08/01/88)
>>... And, DEC ships sources in >>micro-fiche format *free* with every major release, and machine-readable >>source is available for those who want to pay for it. Which, is >>a whole lot more open than Sun, for example. > >... Does this mean that anyone can use the VMS source >as a basis of a port to any other machine and then sell it just like it's >done with UNIX? This certainly is news to me. I wonder why there aren't >as many other machines running VMS as there are DEC machines running UNIX. No. First of all, the guts of VMS (what UNIX folks would call the "kernel") is still written in VAX assembly language, and hence is not portable. Secondly, DEC retains copyright over the sources. The VMS microfiche (which is actually compiler listings) is intended mainly for people who want to read the code to gain a better understanding of VMS internals. It's not in a suitable format for hacking on. The machine readable source (which costs money) is intended mainly for people who want to tailor VMS for a particular application. It doesn't give them the right to re-distribute it. Just clarifying, Rich (former DEC VMS person, now a UNIX person)
gallen@apollo.COM (Gary Allen) (08/01/88)
In article <5838@orstcs.CS.ORST.EDU> kramerj@beasley.UUCP (Jack Kramer - OSU Gene Res) writes: [......] >Sorry about the typo. Does this mean that anyone can use the VMS source >as a basis of a port to any other machine and then sell it just like it's >done with UNIX? This certainly is news to me. I wonder why there aren't >as many other machines running VMS as there are DEC machines running UNIX. Perhaps it's because VMS is/was not designed to be a portable OS and DEC doesn't sell it that way. This was hardly unusual in the days that VAX/VMS was born. In those days, OS's were written by hardware vendors to help sell their hardware; they were never considered to be a seperate product. And unless I'm mistaken, that applies to just about every other OS other than UNIX. Of course it's easy to criticize in hindsight. Let's all get together in about 10 years and look at the dumb things you're doing today. >I certainly hope that the OSF confusion tactic works as well as all >previous IBM and DEC attempts to eliminate UNIX and any other non- >proprietary OS's. Just because YOU find something confusing doesn't make it a "confusion tactic" (after all, you don't understand why VMS doesn't run on non-DEC hardware :)). OSF has made it (I think, reasonably) clear what their intentions are and why. If you don't like that, hey, what can I say? If OSF produces something you like, I think you'll think OSF ok. If they don't, they won't stay around. I hope that sounds like a reasonable compromise to you? Eliminate UNIX? You mean compete against UNIX? Excuse me, we didn't realize that it was a sacred cow. Gary Allen Apollo Computer Chelmsford, MA {decvax,yale,umix}!apollo!gallen "Two half-baths don't add up to a full-bath."
pope@vatican (John Pope) (08/03/88)
In article <377@ksr.UUCP>, richt@breakpoint (Rich Title) writes: > > ... DEC ships sources in > micro-fiche format *free* with every major release, and machine-readable > source is available for those who want to pay for it. Which, is > a whole lot more open than Sun, for example. C'mon, this is really getting silly, even for this conversation. Sun also makes source available for those who want to pay for it. As for free fiche listings, VMS runs on DEC hardware only. This is obviously not the case with SunOS, so I can't imagine what prompted your comparison. > - Rich -- John Pope Sun Microsystems, Inc. pope@sun.COM
dhesi@bsu-cs.UUCP (Rahul Dhesi) (08/04/88)
In article <377@ksr.UUCP> richt@ksr.UUCP (Rich Title) writes: >And, DEC ships sources in >micro-fiche format *free* with every major release, and machine-readable >source is available for those who want to pay for it. DEC sales literature says that DEC makes no assurance that the source you get is the source for the binary that you get. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
henry@utzoo.uucp (Henry Spencer) (08/04/88)
In article <62485@sun.uucp> pope@vatican (John Pope) writes: >... Sun also makes >source available for those who want to pay for it... Well, most of the source. *NOT* all of it. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
jc@minya.UUCP (John Chambers) (08/04/88)
In article <3d999147.d8e9@apollo.COM>, gallen@apollo.COM (Gary Allen) writes: > In article <5838@orstcs.CS.ORST.EDU> kramerj@beasley.UUCP (Jack Kramer - OSU Gene Res) writes: > >I certainly hope that the OSF confusion tactic works as well as all > >previous IBM and DEC attempts to eliminate UNIX and any other non- > >proprietary OS's. > > Just because YOU find something confusing doesn't make it a "confusion tactic" > (after all, you don't understand why VMS doesn't run on non-DEC hardware :)). > OSF has made it (I think, reasonably) clear what their intentions are and > why. If you don't like that, hey, what can I say? If OSF produces something > you like, I think you'll think OSF ok. If they don't, they won't stay around. > I hope that sounds like a reasonable compromise to you? Um, isn't this a bit naive? The past 20 years of the computing field have pretty much proven that IBM can market nearly anything they want, regardless of its quality. Their products have covered the full range from super-shoddy to incredibly-good, and this has relatively little to do with sales. OSF, with IBM's sales budget, could sell a buggy, user-unfriendly Unix to much of the market and convince people that it was good. (Can you say DOS or OS/2? I knew you could! :-) The idea that the "market" will drive out bad products is a nice piece of AdamSmithian Pollyanism, but the facts in the computer field (where most purchase decisions are made by managers who are ignorant of current computers) are clearly otherwise. Not that ATT & friends are likely to do much better. I mean, look at the grand mess they made of shared memory, despite the fact that the Multics people had already shown them how to do it right. :-( > Eliminate UNIX? You mean compete against UNIX? Excuse me, we didn't realize > that it was a sacred cow. Nah; in fact, it's getting to be high time that we started seriously talking about a good follow-on to Unix. We know enough about Unix's good and bad points by now to do a better job. But it ain't gonna come out of any official industry committee, any more that Unix did. We'd just end up with an OS equivalent of Ada, and we all know how much better Ada is than C. (Or maybe it'd be more like PL/I and OS/MVS. ;-) -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
peter@ficc.UUCP (Peter da Silva) (08/05/88)
In article <57@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > Nah; in fact, it's getting to be high time that we started seriously talking > about a good follow-on to Unix. Please... whoever decides to get into this: make one of the requirements be that it be smaller than System V! A non-monolithic kernel would be nice, too. Maybe something like Tunis. (though in 'C' instead of Concurrent Euclid) Anything happening in the Tunis world lately? -- Peter da Silva, Ferranti International Controls Corporation, sugar!ficc!peter. "You made a TIME MACHINE out of a VOLKSWAGEN BEETLE?" "Well, I couldn't afford another deLorean." "But how do you ever get it up to 88 miles per hour????"
brian@apollo.COM (Brian Holt) (08/05/88)
In article <57@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <3d999147.d8e9@apollo.COM>, gallen@apollo.COM (Gary Allen) writes: >pretty much proven that IBM can market nearly anything they want, regardless >of its quality. Their products have covered the full range from super-shoddy >to incredibly-good, and this has relatively little to do with sales. OSF, >with IBM's sales budget, could sell a buggy, user-unfriendly Unix to much >of the market and convince people that it was good. (Can you say DOS or >OS/2? I knew you could! :-) The idea that the "market" will drive out >bad products is a nice piece of AdamSmithian Pollyanism, but the facts >in the computer field (where most purchase decisions are made by managers >who are ignorant of current computers) are clearly otherwise. > Now hold on a minute here. I usually am perfectly willing to sit back and watch people spewing misinformation and arguing amongst themselves, but this is a bit too much. "OSF, with IBM's sales budget"... Huh? I guess your following sentence is true, but so is: "Mt. Xinu, with AT&T's gross income, could send their whole R&D staff to Tahiti for 6 months". OSF is a corporation. OSF is NOT IBM. OSF is NOT DEC. Or Apollo. Or HP. Or Siemens, or anyone else. Those companies certainly founded it, but it is an INDEPENDANT company. Sure, they've got 100 million dollars or so (or enough for about 1,000 person years of work before they need to have an income), but that's it. After that they are on their own. They don't have IBM's sales budget! Now think about it. On that $100 million (or so), they need to buy equipment, hire engineers, marketing hypes (er, types :-), buy Jolt, and everything else. Then keep it running until they can sell enough to cover their expenses. I promise they are going to listen to anyone who is a customer of theirs, or even a potential customer. That may be a lot of money, but it is not infinite. And remember, they really are serious about starting to ship code (something at least) in 18 months. If you *really* want to influence it, send them your resume... =brian Disclaimer: my only connection to OSF is that my office-mate is on loan to them for a few months, leaving me with a double office, and I'd be perfectly happy if they slipped their schedules, as then I'd have all this space to myself for even longer... Oh yeah, these are my thoughts, not anybody elses. -- Internet: brian@apollo.COM UUCP: {decvax,mit-erl,yale}!apollo!brian NETel: Apollo: 508-256-6600 x5694 Home: 617-332-3073 FISA: 617-964-8938 USPS: Apollo Computer, Chelmsford MA Home: 29 Trowbridge St. Newton MA (Copyright 1988 by author. Redistribution for non-commercial purposes allowed)
gerard@tscs.UUCP (Stephen M. Gerard) (08/05/88)
In article <378@ksr.UUCP> richt@ksr.UUCP (Rich Title) writes: >The VMS microfiche (which is actually compiler listings) >is intended mainly for people who want to read the code to gain >a better understanding of VMS internals. It's not in a suitable >format for hacking on. The machine readable source >(which costs money) is intended mainly for people who >want to tailor VMS for a particular application. It doesn't >give them the right to re-distribute it. I think that this is a good idea. It would be great to be able to gain a better understanding of UNIX, or fixing an annoying bug or two by having access to source code for a reasonable sum of money. Of course, since AT&T has taken away the *roff code for the manual pages, it seems unlikely that they would make the source code available to individuals or small businesses for a reasonable sum. Just thought I'd get my .02 in.... -Steve
gallen@apollo.COM (Gary Allen) (08/05/88)
In article <57@minya.UUCP> jc@minya.UUCP (John Chambers) writes: [......] >Um, isn't this a bit naive? The past 20 years of the computing field have >pretty much proven that IBM can market nearly anything they want, regardless >of its quality. Their products have covered the full range from super-shoddy >to incredibly-good, and this has relatively little to do with sales. OSF, >with IBM's sales budget, could sell a buggy, user-unfriendly Unix to much >of the market and convince people that it was good. (Can you say DOS or >OS/2? I knew you could! :-) The idea that the "market" will drive out >bad products is a nice piece of AdamSmithian Pollyanism, but the facts >in the computer field (where most purchase decisions are made by managers >who are ignorant of current computers) are clearly otherwise. To start with OSF is not IBM is not DEC is not Apollo is not HP, ad nauseum. OSF does not have IBM's sales budget. Yeah, I can spell MS-DOS and PC-DOS along with CP/M and a whole bunch of other acronyms. While we all agree that technically superior products are not always the ones that succeed, it is the right of the customer to decide what s/he wants. They obviously have fish-to-fry other than technical merits. I'm not naive enough to believe that "bad" products are driven out of the marketplace, but wise enough to know that unwanted products are, which is not the same thing. By the way, which of those products were "incredibly-good"? Can you spell Peanuts and Chicklets (PC Jr)? >Not that ATT & friends are likely to do much better. I mean, look at the >grand mess they made of shared memory, despite the fact that the Multics >people had already shown them how to do it right. :-( Mach did much better!! Gary Allen Apollo Computer Chelmsford, MA {decvax,yale,umix}!apollo!gallen
vandys@hpisoa1.HP.COM (Andrew Valencia) (08/05/88)
/ hpisoa1:comp.unix.wizards / vandys@hpisoa1.HP.COM (Andrew Valencia) / 8:36 am Jul 27, 1988 /
> I'm no IBM'er (and if you saw me, you'd probably bet I'll never be! :->),
It has been pointed out that this smacks of bigotry. So let me say
that I *still* bet you wouldn't think I'll ever be an IBM'er, but I'll add
that you'd probably say that about some of the IBM'ers, too. I'm told that
some of them have wilder beards than mine... :->
Andyder@sfmag.UUCP (D.Rorke) (08/05/88)
> In article <57@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > >In article <3d999147.d8e9@apollo.COM>, gallen@apollo.COM (Gary Allen) writes: > >pretty much proven that IBM can market nearly anything they want, regardless > >of its quality. Their products have covered the full range from super-shoddy > >to incredibly-good, and this has relatively little to do with sales. OSF, > >with IBM's sales budget, could sell a buggy, user-unfriendly Unix to much > >of the market and convince people that it was good. (Can you say DOS or > >OS/2? I knew you could! :-) The idea that the "market" will drive out > >bad products is a nice piece of AdamSmithian Pollyanism, but the facts > >in the computer field (where most purchase decisions are made by managers > >who are ignorant of current computers) are clearly otherwise. > > > Now hold on a minute here. I usually am perfectly willing to sit back and > watch people spewing misinformation and arguing amongst themselves, but this > is a bit too much. "OSF, with IBM's sales budget"... Huh? I guess your following > sentence is true, but so is: "Mt. Xinu, with AT&T's gross income, could send > their whole R&D staff to Tahiti for 6 months". > > OSF is a corporation. OSF is NOT IBM. OSF is NOT DEC. Or Apollo. Or HP. > Or Siemens, or anyone else. Those companies certainly founded it, but it > is an INDEPENDANT company. Sure, they've got 100 million dollars or so > (or enough for about 1,000 person years of work before they need to have > an income), but that's it. After that they are on their own. They don't > have IBM's sales budget! No, they don't have IBM's sales budget per se, but neither does Microsoft and they managed to sell a few copies of DOS. Now why do you think that was? The point is that there are still many MIS manager types that can only see the color blue when making computer purchasing decisions. So when such a manager decides to go shopping for a UNIX-like system who is he going to call? And what UNIX-like system is his friendly IBM rep going to sell him (after trying very hard to convince the MISmanager (sic) that MVS and VM are really still sufficient to meet all his needs)? This, of course, assumes that there will be some sort of OSF product to sell, something that I'm not yet fully convinced of. > > Now think about it. On that $100 million (or so), they need to buy > equipment, hire engineers, marketing hypes (er, types :-), buy Jolt, > and everything else. Then keep it running until they can sell enough > to cover their expenses. I promise they are going to listen to anyone > who is a customer of theirs, or even a potential customer. That may > be a lot of money, but it is not infinite. And remember, they really > are serious about starting to ship code (something at least) in > 18 months. > Well, you certainly sound like the official OSF spokesman here - surprising considering your disclaimer below. YOU "promise". Well, I guess I've got it on good authority then. I presume you can read the minds and control the behavior of the top OSF management and that's how you can make promises and confidently assure us that they are "serious" about shipping code. I do agree that $100 million is a relatively small investment considering the parties involved. How many times that do you figure they will jointly spend on development of proprietary systems over the same period of time? This reasoning is what has led many observers to question the sincerity of some of the member's commitment to open systems. > If you *really* want to influence it, send them your resume... > > =brian > > Disclaimer: my only connection to OSF is that my office-mate is on > loan to them for a few months, leaving me with a double office, and > I'd be perfectly happy if they slipped their schedules, as then I'd > have all this space to myself for even longer... Oh yeah, these are > my thoughts, not anybody elses. > > > > > -- > Internet: brian@apollo.COM UUCP: {decvax,mit-erl,yale}!apollo!brian > NETel: Apollo: 508-256-6600 x5694 Home: 617-332-3073 FISA: 617-964-8938 > USPS: Apollo Computer, Chelmsford MA Home: 29 Trowbridge St. Newton MA > (Copyright 1988 by author. Redistribution for non-commercial purposes allowed) Disclaimer: These are my opinions and not necessarily those of my employer. Dave Rorke AT&T Bell Laboratories attunix!der
rogers@ofc.Columbia.NCR.COM (H. L. Rogers) (08/06/88)
In article <3dad8e69.d8e9@apollo.COM> gallen@diskless.UUCP (Gary Allen) writes: >In article <57@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >[......] >> OSF, >>with IBM's sales budget, could sell a buggy, user-unfriendly Unix to much >>of the market and convince people that it was good. >To start with OSF is not IBM is not DEC is not Apollo is not HP, ad nauseum. >OSF does not have IBM's sales budget. > OSF does not even *need* IBM's sales budget. IBM sales of the OSF-produced product will give instant credibility to OSF. That seems to be Mr. Chambers' point. OSF will not have to worry about sales budget, software quality, etc. The irony is that IBM probably does not even care, since this business is just a drop in the bucket of their total revenue. -- HL Rogers (hl.rogers@ncrcae.Columbia.NCR.COM)
shankar@hpclscu.HP.COM (Shankar Unni) (08/09/88)
> seems to be Mr. Chambers' point. OSF will not have to worry about > sales budget, software quality, etc. ^^^^^^^^^^^^^^^^ Now, now.. What do you mean by "software quality"? Features? Or lack of bugs? Or a little of both (actually a lot more of the latter than the former)? How do you think IBM sells anything? Product quality is usually priority number 1 (like the Ford commercial :-)) at most of the big players in the business. The features that we jocks like may not be there in their entirety, but you can be sure that what *is* there is thoroughly tested. Hell hath no fury like the DP manager whose end-of-the-month payroll run has been disrupted by a system failure. *That* (and not whizz-bang bells and whistles) is what maks the big companies big. And keeps them big. This is not to imply anything about the actual implementation that OSF is working on. I'm not qualified to comment on that. But I think that we can be certain that OSF's output is going to be rigorously quality-tested by all the companies involved before they put their names to the tapes, because of the diverse types of hardware involved. -- Shankar. "The above opinions are mine and mine only, and do not in any way reflect those of my employer"
funke@csri.toronto.edu (Mark Funkenhauser) (08/10/88)
In article <1213@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes: >In article <57@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: >> Nah; in fact, it's getting to be high time that we started seriously talking >> about a good follow-on to Unix. > >Please... whoever decides to get into this: make one of the requirements >be that it be smaller than System V! > >A non-monolithic kernel would be nice, too. Maybe something like Tunis. >(though in 'C' instead of Concurrent Euclid) Tunis is a rewrite of the UNIX kernel from scratch. The goal was to use all the latest and greatest software engineering techniques. (i.e., modularity, information hiding, concurrency, hierarchical structure ...) A side effect of the Tunis project, was the creation of a language called Concurrent Euclid (CE). This language provided the modularity and concurrency necessary to achieve the original goals. Tunis has been rewritten in a high level language called Turing Plus (T+). (the successor to CE). It still has modules and monitors but it is much more flexible and has added functionality so that almost everything you could do in C you can also do in T+. This language has a formal semantic definition and several features which can be used to produce reliable and correct programs. The whole exercise of TUNIS was to make it modular, maintainable and portable. You lose some performance for the modularity but you gain big in maintainability. You can rewrite the file manager (eg. from 4.1 to 4.2) or change the memory manager (eg. swapping to paging) without effecting (or even looking at) any other part of the system. > >Anything happening in the Tunis world lately? >-- Tunis currently runs on the NS32000 architecture with ports to the 68020 and SPARC are in progress. A port to the 88000 is planned. In '85, there were 2 multi-cpu projects. A master-slave/real-time and a symmetric (distributed) version. Both were completed but the master-slave version had more success. At one point it had 11 processors running at the same time. The robotics group is the prime user of master-slave Tunis. Current research into multiprocessors includes the design and construction of a 100 processor system and using TUNIS as the operating system. This project is called HECTOR. Most recently we are working on using TUNIS as the base for a secure UNIX system. We are convinced that the modularity and hierarchical structure of TUNIS, as well as its implementation language, is exactly what is required for a B2 and higher rated secure systems. Funding for this project has been sporadic although Honeywell-Bull seemed very interested but no major commitment yet. Anybody else out there interested? Mark Funkenhauser - CSRI, University of Toronto { funke@csri.toronto.edu }
ok@quintus.uucp (Richard A. O'Keefe) (08/10/88)
In article <670025@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
:How do you think IBM sells anything? Product quality is usually priority
:number 1 (like the Ford commercial :-)) at most of the big players in the
:business.
Have you ever used VM/CMS? Or its Pascal compiler?madd@bu-cs.BU.EDU (Jim Frost) (08/10/88)
In article <670025@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: |> seems to be Mr. Chambers' point. OSF will not have to worry about |> sales budget, software quality, etc. | ^^^^^^^^^^^^^^^^ |What do you mean by "software quality"? Features? Or lack of bugs? Or a |little of both (actually a lot more of the latter than the former)? | |How do you think IBM sells anything? Product quality is usually priority |number 1 (like the Ford commercial :-)) at most of the big players in the |business. [...] Hell hath no |fury like the DP manager whose end-of-the-month payroll run has been disrupted |by a system failure. Hmm. Wasn't IBM the one that released a version of VM that didn't bother to save the floating point registers when switching between VM's, thus causing much havoc -- especially amongst the scientific communities at several universities which needed to completely recalculate some huge jobs? So much for quality amongst the big boys. Hell hath no fury like the scientist whose thousand-cpu-hours of calculating is invalidated by the lack of a couple of store instructions. |*That* (and not whizz-bang bells and whistles) is what maks the big companies |big. And keeps them big. This is partially right. IBM became big by being reliable; they never did anything really new so what they had was most likely going to work. With the 360 and 370 series machines they got people locked into an architecture; which was the better thing to do when your system was too small? Buy a nice, new, fast machine (real cheap) or stick with IBM and not have to re-code anything? Less headaches with IBM, so they stayed. In addition to this, IBM's service beat (and still beats) the competition hands down. If you have the right service contract they'll bend over backwards to get you running FAST. DP people like that. *THAT'S* why so many of them went with, and stay with, IBM. For sure it's not the programmer's choice to work under MVS ("or any of the other 'S' operating systems" as Barry Shein has said). |Shankar. jim frost madd@bu-it.bu.edu
thomson@hub.toronto.edu (Brian Thomson) (08/10/88)
In article <24355@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: >.... IBM became big by being reliable; they never >did anything really new so what they had was most likely going to >work. Then, in article <4459@cbmvax.UUCP> ditto@cbmvax.UUCP (Michael "Ford" Ditto) adds: >On the other hand, IBM is high up on my list of companies that >contribute to the "state of the art" of high technology. IBM >pours millions of dollars into abstract and obscure research >projects which may or may not show promise of being "profitable". >Look at Mandelbrot's work with fractals, for example. IBM's strategy becomes obvious if you combine these thoughts with some recent events: 1) Sponsor leading-edge research, but 2) Continue to market products based on proven technology. 3) Wait a few years until some smaller, more aggressive, and more agile companies have developed and commercialized the results of (1), then 4) Finally start using it yourself, and while you're at it, 5) Start making some noise about those patents you were careful to file during stage 1 ! Pretty sharp! You can get the benefits of new technology without risking any of your valuable credibility. By the time you use it, someone else has gone out on that limb and established market acceptance. With tongue in only one cheek, -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
bzs@bu-cs.BU.EDU (Barry Shein) (08/10/88)
>Rubbish. First of all, it's "VMS", not "MVS". And, DEC ships sources in >micro-fiche format *free* with every major release, and machine-readable >source is available for those who want to pay for it. Which, is >a whole lot more open than Sun, for example. > > - Rich Rubbish indeed. Read the section on VMS sources in the Digital Desk Reference Guide (published by DEC, several 3 inch binders describing all products.) First, you are basically correct about the fiche, I'm talking about machine readable sources. There is no guarantee that the sources provided will compile and certainly no guarantee that, if they compile, will compile into anything corresponding to a DEC release version of VMS. The price includes no language compiler sources. They are separate and similarly priced items (so you get this list of $45K items.) The sources do not include DECNET sources, they are not available at any price as far as I could tell, this seemed to be confirmed by my queries to DEC. Although this seems less important these days at the time I last seriously looked into it VMS sources required about 500MB of disk and a kernel rebuild reportedly took a standalone 780 overnight. Again, this is probably no big deal anymore but as someone who did UNIX kernel and utility remakes on a whim on a time-shared machine hearing that I would probably have to dedicate a few hundred thousand in equipment to do any realistic work dampened my enthusiasm. Basically, my point is, that DEC never intended there to be source sites for VMS and they were very rare. Last time I tried to find any I found a handful, two or three in the United States. Their intentions were successful for various reasons. Needless to say this is not the case with Unix although specific vendors of course can vary those policies. As a matter of fact, last I checked DEC was quite reasonable about the sources to Ultrix, so it's not a corporate flame here, just that VMS was never designed to make sources available to customers, Unix was. -Barry Shein
littauer@amdahl.uts.amdahl.com (Tom Littauer) (08/10/88)
In article <24355@bu-cs.BU.EDU> madd@bu-it.bu.edu (Jim Frost) writes: > > <deleted> In addition to this, IBM's service beat (and >still beats) the competition hands down. If you have the right >service contract they'll bend over backwards to get you running FAST. Of course I'm biased, but I don't think everyone agrees with this. I'd suggest you check out the Datapro surveys for the last several years. Not to say they aren't good -- they really work at it -- but there ARE people better yet. -- UUCP: littauer@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ames,uunet}!amdahl!littauer DDD: (408) 737-5056 USPS: Amdahl Corp. M/S 337, 1250 E. Arques Av, Sunnyvale, CA 94086 I'll tell you when I'm giving you the party line. The rest of the time it's my very own ravings (accept no substitutes).
pope@vatican (John Pope) (08/10/88)
In article <24355@bu-cs.BU.EDU>, madd@bu-cs (Jim Frost) writes: > >[...] IBM became big by being reliable; they never >did anything really new so what they had was most likely going to >work. Aren't you ignoring things like RISC and Virtual Memory? Of course, this was all about 20 years ago, but to say they "never did anything really new" seems pretty off-base... >jim frost >madd@bu-it.bu.edu -- John Pope Sun Microsystems, Inc. pope@sun.COM
allbery@ncoast.UUCP (Brandon S. Allbery) (08/11/88)
As quoted from <670025@hpclscu.HP.COM> by shankar@hpclscu.HP.COM (Shankar Unni): +--------------- | > seems to be Mr. Chambers' point. OSF will not have to worry about | > sales budget, software quality, etc. | ^^^^^^^^^^^^^^^^ | How do you think IBM sells anything? Product quality is usually priority | number 1 (like the Ford commercial :-)) at most of the big players in the | business. The features that we jocks like may not be there in their entirety, | but you can be sure that what *is* there is thoroughly tested. Hell hath no | fury like the DP manager whose end-of-the-month payroll run has been disrupted | by a system failure. +--------------- Have you told Bill Gates about this recently? There are quite a few examples of Microsoft products that went out quite buggy (can you say "MSC"? [It took them 4 tries!!!] How about "MS Word 3.0 on Macintosh"? And I recall a Xenix release for the original ncoast which reformatted our hard drive while running, although that may have been Tandy's fault). A company as big as Microsoft or IBM can sell by name value alone; all too often this results in the product value approaching zero. A company which operates like IBM (i.e. proprietary hardware and software) also has a captive audience, which makes product testing an even lower priority. This is considered to be good for the Almighty Bottom Line ("Gee, we can sell *anything*, whether it works or not! Why waste time and money testing it first? That hurts the bottom line!"). (In case it's not obvious, I think that when we get around to hanging the lawyers, the MBAs ought to be hanged at the same time. But I'll get off the soapbox now....) -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
mudd-j@pike.cis.ohio-state.edu (John R. Mudd) (08/11/88)
In article <269@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <670025@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >:How do you think IBM sells anything? Product quality is usually priority >:number 1 (like the Ford commercial :-)) at most of the big players in the >:business. > >Have you ever used VM/CMS? Or its Pascal compiler? I may be putting my life and professional career on the line by saying this, but I *liked* VM/CMS from a user point-of-view. The shop I worked at had a IBM 3090 running VM/XA with 200+ users, and that system was FAST. Not like some of the delays I've had on some of these Unix-boxes. Of course, they're not as big as a 3090, which is IBM's top-of-line model. I don't know much of anything about VM from a system programmer's POV, so I can't comment on that aspect. And please, don't think I'm an IBM lover, either. I despise IBM for what I consider their unethical practices of putting competitors out of business (yea, yea, it's part of big business ... bull!!) and other things, like a being a monopoly. But one cannot deny that IBM has put out good (ok, reasonably good .... all right, fair) products from time to time, and then backed them up with incredibly good customer service. And if you want to take this any further, take it to email (I hate flame wars). John -=- ------------------------------------------------------------------------------- John R. Mudd Department of Computer & Information Science The Ohio State University, 2036 Neil Avenue, Columbus, Ohio, USA 43210-1277 email: mudd-j@cis.ohio-state.edu
gwyn@smoke.ARPA (Doug Gwyn ) (08/11/88)
In article <63717@sun.uucp> pope@vatican (John Pope) writes: >>[...] IBM became big by being reliable; they never did anything >>really new so what they had was most likely going to work. >Aren't you ignoring things like RISC and Virtual Memory? Funny, the Burroughs salespeople used to say that IBM's "introduction" of such features helped Burroughs sales, because finally there was a market demand for what Burroughs had already been supplying..
christie@kylie.oz (Chris Tham) (08/11/88)
In article <62485@sun.uucp> pope@vatican (John Pope) writes: >In article <377@ksr.UUCP>, richt@breakpoint (Rich Title) writes: >> >> ... DEC ships sources in >> micro-fiche format *free* with every major release, and machine-readable >> source is available for those who want to pay for it. Which, is >> a whole lot more open than Sun, for example. > >C'mon, this is really getting silly, even for this conversation. Sun also makes >source available for those who want to pay for it. As for free fiche listings, >VMS runs on DEC hardware only. This is obviously not the case with SunOS, so I >can't imagine what prompted your comparison. That's really funny. I thought SunOS only runs on Sun hardware. If I was trying to make SunOS run on an IBM PC/XT :-) for example, I would have to rewrite a _lot_ of code, especially like ALL the device drivers and 68020/SPARC assembly. Most of the libraries like PixRect would probably need to be rewritten as well. The point is, SunOS is either wholly or partially derived from UNIX, either BSD4.2 or System V R2, source. Giving SunOS microfiche *free* with every release of SunOS would probably contravene Sun's existing software licence with AT&T and/or Berkeley. So why doesn't AT&T release *free* microfiche copies of System V? Simple. Because UNIX is designed to be a _portable_ operating system, releasing unrestricted source in any form would be like shooting oneself in the foot, especially if one is licencing said source code to other commercial organizations for big bucks. -- ACSNET/CSNET: christie@kylie.oz.AU ARPA: christie%kylie.oz.AU@UUNET.UU.NET JANET: christie%kylie.oz@uk.cc.ucl.cs PHONE: +612 235-0255 UUCP: {uunet,hplabs,mcvax,ukc,nttlab}!munnari!kylie.oz!christie MAIL: Chris Tham, Optech Research Pty Ltd, Level 60 MLC Centre Sydney 2000 AUST
ok@quintus.uucp (Richard A. O'Keefe) (08/11/88)
In article <19709@tut.cis.ohio-state.edu> mudd-j@pike.cis.ohio-state.edu (John R. Mudd) writes: >In article <269@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>In article <670025@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes: >>:How do you think IBM sells anything? Product quality is usually priority >>:number 1 (like the Ford commercial :-)) at most of the big players in the >>:business. >> >>Have you ever used VM/CMS? Or its Pascal compiler? > >I may be putting my life and professional career on the line by saying this, >but I *liked* VM/CMS from a user point-of-view. I can see your point of view, I mean, 80-column records and tape drives numbered in hexdecimal are so nostalgic (or kathedralgic, to coin a word). But the topic was "Product quality", not "user interface". I'm talking about ordinary user-level programs written in PL/I being able to crash a user's virtual machine and trash a virtual disk on the way. I'm talking about people having to rewrite their programs in SAS (yes, SAS) because the Pascal compiler was, hmm, not a "priority number 1" program. I'm talking about a site where the terminal concentrators crashed every day and IBM's view was "tough luck, you should be using 3270s." I'm talking about VSAM frequently reporting error numbers that weren't in the manual. And so on. IBM have many strengths, and VM/CMS software is no more flaky than a lot of other stuff, but it is nothing special either.
pope@vatican (John Pope) (08/12/88)
In article <8329@smoke.ARPA>, gwyn@smoke (Doug Gwyn ) writes: >In article <63717@sun.uucp> pope@vatican (John Pope) writes: >>>[...] IBM became big by being reliable; they never did anything >>>really new so what they had was most likely going to work. >>Aren't you ignoring things like RISC and Virtual Memory? > >Funny, the Burroughs salespeople used to say that IBM's "introduction" >of such features helped Burroughs sales, because finally there was a >market demand for what Burroughs had already been supplying.. I had always assumed the IBM machines predated the Burroughs 5000, due to "IBM invented virtual memory" statements I'd seen several places. Gullible me. In fact, someone mailed me that the (circa 1960) ATLAS machine predates either of them. As for RISC, did Burroughs have anything prior to the 801 ? Will they be serving IBM with patent violation notices soon #:-) ? -- John Pope Sun Microsystems, Inc. pope@sun.COM
gallen@apollo.COM (Gary Allen) (08/12/88)
In article <19709@tut.cis.ohio-state.edu> mudd-j@pike.cis.ohio-state.edu (John R. Mudd) writes: >I may be putting my life and professional career on the line by saying this, >but I *liked* VM/CMS from a user point-of-view. The shop I worked at had a [......] >------------------------------------------------------------------------------- > John R. Mudd Department of Computer & Information Science > The Ohio State University, 2036 Neil Avenue, Columbus, Ohio, USA 43210-1277 > email: mudd-j@cis.ohio-state.edu You're right; your name is now Mudd on this newsgroup! Gary Allen Apollo Computer Chelmsford, MA {decvax,yale,umix,mit-eddie}!apollo!gallen
jejones@mcrware.UUCP (James Jones) (08/12/88)
In article <63717@sun.uucp>, pope@vatican (John Pope) writes: > In article <24355@bu-cs.BU.EDU>, madd@bu-cs (Jim Frost) writes: > > > >[...] IBM became big by being reliable; they never > >did anything really new so what they had was most likely going to > >work. > > Aren't you ignoring things like RISC and Virtual Memory?... No doubt many people will point at the Ferranti Atlas and Burroughs large systems (B5000 et seq.) as virtual memory systems predating the 370 by quite a few years. I think that a more accurate characterization of IBM is that they never bring out anything new until they have to. IBM "legitimatizes" innovations, whether they are IBM's or somebody elses, entering the market years after others have done so--look at personal computers, relational databases, virtual memory, and now RISC machines for examples. James Jones (whose opinions are his own, and not necessarily those of any other eukaryotic creature or legal fiction)
apm@oasis.icl.stc.co.uk (Andrew Merritt x2109) (08/15/88)
%>
%>[...] IBM became big by being reliable; they never
%>did anything really new so what they had was most likely going to
%>work.
%
%Aren't you ignoring things like RISC and Virtual Memory? Of course, this
%was all about 20 years ago, but to say they "never did anything really
%new" seems pretty off-base...
%
Ah, the Big Blue version of history again. IBM did not invent Virtual Memory.
See the work done by Aspinall et al. on the MU5 at Manchester University.
Andrew.
--
signed: Andrew Merritt (763) 2109
local: apm global: apm@iclbra.uucp
apm@icl.stc.co.uk
MSDOS: Just say NO. ...!uunet!mcvax!ukc!stc!iclbra!apmgwyn@smoke.ARPA (Doug Gwyn ) (08/16/88)
In article <313@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >... I think that if Unix is to survive it needs a mass cleanup to go >*back* to its original idea of "small is beautiful" and get some of the >junk out of it ... The UNIX product will "survive" even with all the added cruft. The extra baggage persists because none of the marketing types will seriously consider changing the system in ways that cause massive amounts of existing customer applications to break. The correct solution would have been to resist adding features in the first place and to change kernel functionality only after considerable careful thought. In fact the Bell Labs "research" version of UNIX has suffered far less from feeping creaturism than the commercial products (4.nBSD & System V). Generally the real UNIX gurus are well aware of the problem. Even many of the AT&T UNIX product development staff understand the basic philosophy to some degree; to take one of your examples, the tty driver has indeed been converted to STREAMS, it just wasn't ready for Release 3.0. For another example, in response to a call for public-domain contributions I sent Berkeley a "cat" with NO options that preserves record structure. 9th Edition UNIX has a similar version of "cat". We really DO want to stamp out the cruft. In the research world, it appears to still be possible. The commercial versions of UNIX are probably a lost cause due to uneducated customer demand for features. Features sell a system, even though its underlying logic determines its real worth. There are many good new ideas that can be incorporated into future operating systems. Whether it would be fair to call such a system "UNIX" is a debatable point. There is one in the works called "Plan 9" that embodies some good concepts.. The best operating systems really are developed by small teams working with little interference; this has been demonstrated several times by history. That doesn't keep managers from missing the lesson and organizing huge project teams! Maybe the real problem lies in typical technical management?
aad@stpstn.UUCP (Anthony A. Datri) (08/17/88)
In article <722@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes: >In article <63717@sun.uucp>, pope@vatican (John Pope) writes: >>In article <24355@bu-cs.BU.EDU>, madd@bu-cs (Jim Frost) writes: >>>[...] IBM became big by being reliable; they never >>>did anything really new so what they had was most likely going to >>>work. >> Aren't you ignoring things like RISC and Virtual Memory?... >No doubt many people will point at the Ferranti Atlas and Burroughs large >systems (B5000 et seq.) as virtual memory systems predating the 370 by >quite a few years. Actually, I think IBM became big largely by being there. They built up a decent office machine business, and they started leasing mid-range computers, which made them affordable. Then around 1963-4, they invested something like One Billion bucks in the 360 project. Of course, as a side effect, they're still building 360's, and still running OS/360 on them. At one point IBM modified two (2) 360/65's to have virtual memory, and called it the 360/67, as a test to see if virtual memory would work. CMU had one of them. As I understand it, the 370 is basically a 360 with vm. This is all from the various computer history books I have, recalled from memory. IBM has indeed come up with a lot of things -- the floppy, for example. One of my gripes with them is that they refuse to abandon the brain-damage of yesteryear. EBCDIC. Operating systems that treat users like card readers. EBCDIC. Stupid networking. EBCDIC. And, of course, there's the interesting bit that KERMIT came about because of Columbia's difficulites in transferring files to and from anIBM mainframe. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad
bill@zycor.UUCP (bill) (08/17/88)
} I can only hope that those involved will hear this }lonely voice in the crowd (probably a minority opinion) and just consider }the consequeces as Unix grows to consume all available resources. } }I will get off my soapbox now and begin to line the mailbox with asbestos }(again) since I can hear them flames-a-commin'! :-) } }-- }scott barman ..!gatech!dtscp1!scott }Digital Transmissions Systems, Inc. }Duluth, Georgia Well, those flames may be a-comin' but maybe not. Frankly, I agree with you.
res@ihlpe.ATT.COM (Rich Strebendt) (08/19/88)
In article <1991@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: > At one point IBM modified two (2) 360/65's to have > virtual memory, and called it the 360/67, as a test to see if virtual > memory would work. CMU had one of them. As I understand it, the 370 > is basically a 360 with vm. Almost right. There were a fair number of 360/67's and 370/168's running the TSS 360/370 operating system. The Bell Labs Indian Hill computer center had (I believe) six /67's and /168's at one point being used for hardware and software development for Electronic Switching Systems. To make the 360/67, a unit called the Direct Access Translator (familiarly known as the DAT box) was added to a 360/65. This hardware was included in the 370 machines. The DAT box could be turned off to make the machine back into a /65. At the Indian Hill Computation Center when the 360/67 was introduced, it was used as a /67 during the day running TSS, then was switched back to a /65 to help process the backlogged work on the OS side of the computer center (as one of as many as six slave processors on an ASP network). Rich Strebendt [iwsl6|ihlpe|ihaxa]!res [cuuxf|cuuxg]!iw1res!res
jgp@moscom.UUCP (Jim Prescott) (08/23/88)
>Operating systems that treat users like card readers.
Gee, that's even worse than sendmail complaining about users who are not ttys!aland@infmx.UUCP (Dr. Scump) (08/25/88)
In article <1991@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: > > This is all from the various computer history books I have, recalled > from memory. IBM has indeed come up with a lot of things -- the > floppy, for example. One of my gripes with them is that they refuse > to abandon the brain-damage of yesteryear. EBCDIC. Operating systems > that treat users like card readers. EBCDIC. Stupid networking. EBCDIC. And *what* is the big problem with EBCDIC, except that "it's not ASCII"? At least EBCDIC had the foresight to use an 8-bit character set from the beginning (IMHO, 8-bit ASCII is a kludge by comparison). Some people can't get used to having digits > letters and noncontiguous codes for letters; I can't get used to having uppercase letters be *less* than lowercase. I also prefer EBCDIC hex dumps to ASCII octal dumps. Does that make me brain-damaged? (let me rephrase that; do these factors *alone* make me brain-damaged? :-] :-] :-] ) The thing I *really* can't get used to: having every character I type (in raw mode applications, anyway) cause an interrupt, instead of being able to key in a screen worth before bothering the host system... To each his own... -- Alan S. Denney | Informix Software, Inc. | {pyramid|uunet}!infmx!aland Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"
madd@bu-cs.BU.EDU (Jim Frost) (08/26/88)
In article <381@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: |And *what* is the big problem with EBCDIC, except that "it's not ASCII"? How about the "n" different versions of EBCDIC? It's an IBM standard and yet it's different on the three different types of IBM hardware I use (IBM System/32, System/23 Datamaster, and System/34, 36, and 38). ASCII is ASCII anywhere.... jim frost madd@bu-it.bu.edu
tim@introl.uucp (Tim Chase) (08/26/88)
In article <381@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: >The thing I *really* can't get used to: having every character I type >(in raw mode applications, anyway) cause an interrupt, instead of being >able to key in a screen worth before bothering the host system... Simple, just throw a bit of hardware at it in the form of an intelligent I/O processor and many of those interrupts can become a distant memory. It doesn't seem as if every system needs one, though they are readily available in the PC Unix market. Hopefully this wasn't an implication that interrupt-per-character is an intrinsic feature of Unix. If, however, a process really wants to see every character as it is typed, I don't see how this interrupt can be avoided. Oh yeah, don't you think those "raw mode applications" are have a superior user interface to that of your block-mode terminal? If they don't, at least you can change the programs. If you don't like your block-mode terminal's editing features, you're out of luck. In summary, I think that having the ability to use a "raw" mode allows more friendly, interactive programs to be written and to be run on a wider range of hardware. -- UUCP: {uunet,uwvax!uwmcsd1}!marque!introl!tim Phone: +1 414 276-2937
mouse@mcgill-vision.UUCP (der Mouse) (08/26/88)
In article <381@infmx.UUCP>, aland@infmx.UUCP (Dr. Scump) writes: > In article <1991@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: >> One of my gripes with [IBM] is that they refuse to abandon the >> brain-damage of yesteryear. EBCDIC. > And *what* is the big problem with EBCDIC, except that "it's not > ASCII"? > Some people can't get used to having digits > letters and > noncontiguous codes for letters; I can't get used to having uppercase > letters be *less* than lowercase. I want to step through the letters from A to Z (or a to z) a lot more often than I want to compare an uppercase letter with a lowercase letter. Therefore, I'd rather have contiguous letters. Particularly since I don't lose the capability to compare two letters for case, just that the test goes the other way. > I also prefer EBCDIC hex dumps to ASCII octal dumps. Dumping in either hex *or* octal is silly when you want to look at memory locations as characters, a viewpoint which is implied by discussing ASCII vs EBCDIC. If I'm doing dumps of this sort, I prefer a hex dump to an octal dump (unless it's for a PDP-8 :-). > Does that make me brain-damaged? (let me rephrase that; do these > factors *alone* make me brain-damaged? :-] :-] :-] ) No, just somewhat twisted :-] > The thing I *really* can't get used to: having every character I type > (in raw mode applications, anyway) cause an interrupt, instead of > being able to key in a screen worth before bothering the host > system... Why should this bother you? How come you even notice this? Seems to me it doesn't matter who handles it; *someone* has to handle your keystrokes, either the "host" cpu or a cpu sitting in the "terminal", dedicated to doing nothing else. If interrupts are cheap enough (and UNIX box manufacturers generally take care that they are), it's not an undue load on it.... I've got over half of a VAX 750 cpu now doing nothing but hanging on my every keystroke, to mangle a metaphor. A modern UNIX box is often close to a single-user machine, which is what the processor in a 3270 really is - a (specialized) single-user machine. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rroot@edm.UUCP (Stephen Samuel) (08/27/88)
From article <1265@mcgill-vision.UUCP>, by mouse@mcgill-vision.UUCP (der Mouse): > In article <381@infmx.UUCP>, aland@infmx.UUCP (Dr. Scump) writes: >> In article <1991@stpstn.UUCP>, aad@stpstn.UUCP (Anthony A. Datri) writes: >>> One of my gripes with [IBM] is that they refuse to abandon the >>> brain-damage of yesteryear. EBCDIC. >> And *what* is the big problem with EBCDIC, except that "it's not >> ASCII"? [some comments about non-contiguous alphabets and how suggestions that you can't do ASCII hex dumps (?!)] >> The thing I *really* can't get used to: having every character I type >> (in raw mode applications, anyway) cause an interrupt, instead of >> being able to key in a screen worth before bothering the host >> system... > > Why should this bother you? How come you even notice this? Seems to > me it doesn't matter who handles it; *someone* has to handle your > I've got over half of a VAX 750 cpu now doing nothing but hanging on my > every keystroke, to mangle a metaphor. A modern UNIX box is often .. You almost make it sound like it takes almost half the 750's CPU power just to handle your keyboard input. Comments like that can scare some people. A 750 may be 'slow' by today's standards, but they're not THAT bad :-). Running stuff thru the ethernet gave me a good idea as to just how cheap it is to handle char-at-a-time keyboard data. (can you say "cheap like borsht") Duping the stuff from our sun, thru a 750 to a 780 (about 1KM away) produced an almost negligble load on the 750-- even with the load of 2 TCP packets for each keyboard character (1 each, inbound and outbound). UNIX (and most other ASCII systems) uses char-at-a-time input sometimes, but you can often get away with having a front end communications processor (FECP) convert things to line-at-a-time and only interrupt the CPU on buffer-end or other special conditions. There are many UNIX systems out there that already support that sort of pre-processing AND ALLOW IT TO BE TURNED OFF! This is where UNIX has it hands down over an IBM-style system. There are lots of 3270 emulators available for UNIX system, but HAVE YOU EVER TRIED RUNNING vi FROM A 3270???? -- I have... once. I think that the Amdahl people may know a LOT more about this. In general: I'd much rather put up with the, relatively minor, cost of char- at-a-time input than be stuck with the BrainDead'isms of a system that treats terminals like card punches with a VDT attached. -- ------------- Stephen Samuel (userzxcv@ualtamts.bitnet or alberta!edm!steve)
bzs@encore.UUCP (Barry Shein) (08/27/88)
>How about the "n" different versions of EBCDIC? It's an IBM standard >and yet it's different on the three different types of IBM hardware I >use (IBM System/32, System/23 Datamaster, and System/34, 36, and 38). >ASCII is ASCII anywhere.... > >jim frost Correct, add to that list at least two different interpretations of EBCDIC on the 370 architecture, note that on the "green card" from IBM there are two columns referencing the following note: 1. Two columns of EBCDIC graphics are shown. The first gives IBM standard U.S. bit pattern assignments. The second shows the T-11 and TN text printing chains (120 graphics.) What that means in practice (as we lived with painfully at BU) is that if you transfer an ASCII file/mail whatever to an IBM you must know if its intention was printing or otherwise. Add to that the fact that IBM327x terminals don't have things like curly braces (or maybe it's that they can display them but can't type them in) and you really do have a pretty random environment, it doesn't take too many choices/alternatives to just break down any image that things are under control. Don't speculate about it if you don't know what I'm referring to from experience. EBCDIC is not inherently wrong (I mean, it's only an encoding table), but IBM never really standardized it in any way useful from machine to machine or device to device. That's how "standards" die. -Barry Shein, ||Encore||
gwyn@smoke.ARPA (Doug Gwyn ) (08/28/88)
In article <3262@edm.UUCP> rroot@edm.UUCP (Stephen Samuel) writes: >.. You almost make it sound like it takes almost half the 750's CPU power >just to handle your keyboard input. Comments like that can scare some people. >A 750 may be 'slow' by today's standards, but they're not THAT bad :-). Yes, they are. It takes about 30% of a 750 just to output data at 9600 baud via a DZ11 interface, using the Berkeley implementation (noticeably better with streams, or with a KMC11-B I/O processor). And running an application in "raw mode" causes so many context switches per character that the system is noticeably loaded just getting characters to the application. >In general: I'd much rather put up with the, relatively minor, cost of char- >at-a-time input than be stuck with the BrainDead'isms of a system that treats >terminals like card punches with a VDT attached. I seem to recall this discussion started as "where should input editing be done". The "editing in the terminal" I mentioned did not imply "block mode"; that notion was brought up by others. In fact I routinely edit text in my terminal before sending it to any of our operating systems, some of which have no special support for intelligent terminals. I just snarf what I need with the mouse by highlighting it from any window buffer (scrolling via an "elevator" if necessary) with the left button depressed, edit it locally into what I need (using highlighting with "cut", "snarf", and "paste" menu items, also typing in new text), and "send" it to the appropriate window (just as though it had been typed on the keyboard) via another menu option. This is entirely built into the AT&T model 630 terminal and can be used any time during normal ASCII terminal operations; at least one window is available with this feature from the moment the terminal is powered on (unlike the 5620). (The 630 also supports multiple fonts and down-loaded applications, such as the "sam" editor that really is a general-purpose text editor by design, but that's not germane to this particular issue.) Editing works great, the host is unaware of it, and I don't know how I could stand being without it. I know of no other terminal in the $2000 price range that is nearly as nice as the 630.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (08/30/88)
In article <381@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: [ ... ] | *less* than lowercase. I also prefer EBCDIC hex dumps to ASCII octal | dumps. Does that make me brain-damaged? (let me rephrase that; do these | factors *alone* make me brain-damaged? :-] :-] :-] ) No, no, it's probably due to other causes...;-) | The thing I *really* can't get used to: having every character I type | (in raw mode applications, anyway) cause an interrupt, instead of being | able to key in a screen worth before bothering the host system... No smiley on this one; having each character cause an interrupt is not related to either UNIX or ASCII. UNIX supports having a smart device driver which handles the characters and stores data via DMA, although it costs more to have smarts on the serial or IP device. An example of this is the Arnet board for Xenix or ix386, which does just what you imply. Since STTY options allow some character level editing, SOMETHING has to look at every character to provide for delete character and line. It need not be the main CPU. ================ flame suit and heavy duty jock on ================ one of the few things I like about DOS and VMS is that the characters are echoed as they are read, not as they are typed. This prevents display of info designed to be read "no echo." Fortunately there seems to be no reason why this can't be done in a device driver, even if it's not (I would like to think it is and I haven't found it). I expect to be told by some people that this would be bad because it's a feature of ugly o/s's, but I'm going to write that device driver one day. ================================================================ -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/01/88)
In article <8392@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Yes, they are. It takes about 30% of a 750 just to output data at 9600 baud >via a DZ11 interface, using the Berkeley implementation... Do you mean 30% of a 750 sending 9600 bps via a single serial line, or concurrently on all 8 lines on a dz11? -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
gwyn@smoke.ARPA (Doug Gwyn ) (09/01/88)
In article <3821@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <8392@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >Do you mean 30% of a 750 sending 9600 bps via a single serial line, or >concurrently on all 8 lines on a dz11? A single line. Actually, this might the the effective loss of throughput for dumping data via the DZ line from a user-mode process, rather than actual system load factor. (This figure was measured at Bell Labs; our sole 750 wandered away long ago.)
irene@pyr1.cs.ucl.ac.uk (09/02/88)
/* Written 7:13 am Aug 28, 1988 by gwyn@smoke.ARPA in pyr1.cs.ucl.ac.uk:comp.unix.wizards */ /* ---------- "Re: AT&T Joining OSF (actually: BD " ---------- */ In article <3262@edm.UUCP> rroot@edm.UUCP (Stephen Samuel) writes: >.. You almost make it sound like it takes almost half the 750's CPU power >just to handle your keyboard input. Comments like that can scare some people. >A 750 may be 'slow' by today's standards, but they're not THAT bad :-). Yes, they are. It takes about 30% of a 750 just to output data at 9600 baud via a DZ11 interface, using the Berkeley implementation (noticeably better with streams, or with a KMC11-B I/O processor). And running an application in "raw mode" causes so many context switches per character that the system is noticeably loaded just getting characters to the application. >In general: I'd much rather put up with the, relatively minor, cost of char- >at-a-time input than be stuck with the BrainDead'isms of a system that treats >terminals like card punches with a VDT attached. I seem to recall this discussion started as "where should input editing be done". The "editing in the terminal" I mentioned did not imply "block mode"; that notion was brought up by others. In fact I routinely edit text in my terminal before sending it to any of our operating systems, some of which have no special support for intelligent terminals. I just snarf what I need with the mouse by highlighting it from any window buffer (scrolling via an "elevator" if necessary) with the left button depressed, edit it locally into what I need (using highlighting with "cut", "snarf", and "paste" menu items, also typing in new text), and "send" it to the appropriate window (just as though it had been typed on the keyboard) via another menu option. This is entirely built into the AT&T model 630 terminal and can be used any time during normal ASCII terminal operations; at least one window is available with this feature from the moment the terminal is powered on (unlike the 5620). (The 630 also supports multiple fonts and down-loaded applications, such as the "sam" editor that really is a general-purpose text editor by design, but that's not germane to this particular issue.) Editing works great, the host is unaware of it, and I don't know how I could stand being without it. I know of no other terminal in the $2000 price range that is nearly as nice as the 630. /* End of text from pyr1.cs.ucl.ac.uk:comp.unix.wizards */