gnu@sun.uucp (John Gilmore) (07/16/85)
Ron Heiby at ihnp4!cuae2!heiby responded to a user's question "why doesn't AT&T distribute [possibly optional] Berkeley enhancements, I hear they use them in house anyway" with: > As to any other BSD developments: They > are all known of and looked at by AT&T developers. Some appear in System V, > like "cat -v" and "ls -RadCxmnlogrtyucpFbqisf" and "mailx" (alias Mail). The > thing to remember is that Berkeley is (supposed to be) in the education > business. They do a good job by letting students experiment. AT&T is in the > stable computing environment business. We do a good job by making darn sure > that what we do doesn't break something (like a shell script or worse) and > that we spend our efforts spending resources on the most important/needed > enhancements first. By implication that puts all commercial vendors of 4.2BSD systems in the "unstable computing environment business"?
hammond@petrus.UUCP (Rich A. Hammond) (07/17/85)
> By implication that puts all commercial vendors of 4.2BSD systems > in the "unstable computing environment business"? Judging by how often we find bugs and our machines crash, I'd say yes, runnning 4.2 BSD is being in an unstable computing environment.
heiby@cuae2.UUCP (Ron Heiby) (07/17/85)
In article <2423@sun.uucp> gnu@sun.uucp (John Gilmore) writes: >By implication that puts all commercial vendors of 4.2BSD systems >in the "unstable computing environment business"? There there, John. I was talking about the University of CA at Berkeley. I was not talking about any commercial vendors. I have no knowledge of Sun's quality control, although I have heard good reports from users of Sun systems. BTW, in my previous job, I used a commercial port of System III to a M68000 based system. The quality on that product was marginal. So, I know enough not to be talking about quality of commercial products based only on their porting base (although I have my favorite). My remarks dealt only with the orientation of the organization that puts out System V versus the organization that puts out BSD. Both are available. It is up to the organization that purchases either to understand the pros and cons involved. I'm sorry my remarks could have been mis-interpreted. -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
davest@daemon.UUCP (Dave Stewart) (07/18/85)
In article <2423@sun.uucp> gnu@sun.uucp (John Gilmore) writes: >> ... We do a good job by making darn sure >> that what we do doesn't break something (like a shell script or worse) and >> that we spend our efforts spending resources on the most important/needed >> enhancements first. > >By implication that puts all commercial vendors of 4.2BSD systems >in the "unstable computing environment business"? There are also plenty of examples where AT&T adds a BSD feature, but changes the command or system call name or syntax. Isn't that referred to as the NIH (Not Invented Here) syndrome? When will AT&T (and DEC for that matter) realize that UC Berkeley is NOT a competitor? Stepping down from his soapbox ... -- David C. Stewart uucp: tektronix!davest Small Systems Support Group csnet: davest@TEKTRONIX Tektronix, Inc. phone: (503) 627-5418
guy@sun.uucp (Guy Harris) (07/21/85)
> > By implication that puts all commercial vendors of 4.2BSD systems > > in the "unstable computing environment business"? > > Judging by how often we find bugs and our machines crash, I'd say yes, > runnning 4.2 BSD is being in an unstable computing environment. John didn't say "by implication that says 4.2BSD is an unstable computing environment", he said "by implication that puts all *commercial* vendors of 4.2BSD systems in the 'unstable computing environment business'." My machine is supplied by a "commercial vendor of 4.2BSD systems" (as is John's, I suspect :-) :-) :-)), and, well, 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00 It's been up longer. The only times it's crashed due to an OS bug are a few times when some pre-release software hung and it had to be rebooted (that problem hasn't recurred, and it wasn't the 4.2BSD base's fault) and once when it crashed due to some code I'd added (which, for the benefit of those of you who sneer at "lint", would have been reported by "lint"ing the kernel). I've rarely found bugs, and most of them have been pretty small. (Several pieces of code from the System V release would have crashed on this machine, because they dereference null pointers, so the Berkeley people aren't the only people who ship buggy UNIX software.) Then again, the "stability" being discussed here is not resistance to crashes but the absence of system changes that break existing code. Yes, 4.2BSD has introduced some changes which break existing code. So has System V. (Remember the time they decided to enforce the "only one external definition" rule? The old COMMON-block semantics came back faster than Old Coke...) Guy Harris
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/21/85)
> There are also plenty of examples where AT&T adds a BSD feature, > but changes the command or system call name or syntax. Isn't that > referred to as the NIH (Not Invented Here) syndrome? When will AT&T > (and DEC for that matter) realize that UC Berkeley is NOT a competitor? There may be some "NIH" syndrome at work, but you should also appreciate that BSD software is not necessarily up to commercial standards, so it might need some adaptation before being supported by a commercial outfit. Unfortunately, AT&T has been picking up some of the WORST features from BSD. cat -v, ls -[a-z][A-Z], yuck.
jg@mit-eddie.UUCP (Jim Gettys) (07/21/85)
In article <2453@sun.uucp> guy@sun.uucp (Guy Harris) writes: >...................................................... My >machine is supplied by a "commercial vendor of 4.2BSD systems" (as is >John's, I suspect :-) :-) :-)), and, well, > > 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00 > >It's been up longer. The only times it's crashed due to an OS bug are a few >times when some pre-release software hung and it had to be rebooted (that >problem hasn't recurred, and it wasn't the 4.2BSD base's fault) and once >when it crashed due to some code I'd added (which, for the benefit of those >of you who sneer at "lint", would have been reported by "lint"ing the >kernel). .................. I have seen an amusing bug in ruptime on our machines here (running a "not commercially supported" version of 4.2). mit-zeus up ??+17:42, 0 users, load 0.01, 0.03, 0.03 This occurs if a machine has been up more than 99 days...... Several other machines on that local net had been up over 80 days, so it was not a fluke. Unfortunately, we had a power failure at 111 days. Sigh.... I suppose we should all get up on our high horses and swear at Berkeley for "buggy" software, but I for one am willing to forgive them for this particular bug. Jim Gettys Project Athena
root@bu-cs.UUCP (Barry Shein) (07/21/85)
>From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) >Subject: Re: instability in Berkeley versus AT&T releases >> There are also plenty of examples where AT&T adds a BSD feature, >> but changes the command or system call name or syntax. Isn't that >> referred to as the NIH (Not Invented Here) syndrome? When will AT&T >> (and DEC for that matter) realize that UC Berkeley is NOT a competitor? > >There may be some "NIH" syndrome at work, but you should also appreciate >that BSD software is not necessarily up to commercial standards, so it >might need some adaptation before being supported by a commercial outfit. > >Unfortunately, AT&T has been picking up some of the WORST features from >BSD. cat -v, ls -[a-z][A-Z], yuck. Ok Doug, it's fighting time. If by 'commercial standards' you mean bug-free, I don't see where 4.2 has any corner on the bug market. For example, you should see how many core-dumps per minute I get from sdb on my 3B5 (the only debugger, no adb or dbx, this was under R1, maybe it got better under R2, but maybe some bugs are out under 4.3, no?) It won't even start about 25% of the time, just dies (yes, that's vanilla C programs, trust me, its buggy as heck.) And 3BNet...? C'mon, that's not a feature, that's a bug. How much does dumb, incompatible, NIH design count? I mean, correct me if I'm wrong, but doesn't networking have something to do with speaking to other machines? I fought DECNET here, everyone fought SNA and now this? Ok, they're gonna pick up TCP/IP cause now they got a $1Billion contract from NSA, I'm glad, but I'm not impressed by the decision-making process. As far as I can tell, you've got to have the sources to enable FLEXNAMES (I do and am.) Unfortunately, I am still trying to re-build comp because a source file is just missing. I understand the arguments to keep ids down (and they're good arguments, I agree) but that's a funny compromise. And things that are just plain missing that are mostly taken for granted these days, like pty's (re: 4.2, VMS, tops-20)?? (forget sxts.) And which file system is up to commercial standards? I think I have a lot more faith in 4.2 than the SYSV 4.1 clone (how come 4.2 sites don't even have an 'fsdb' [file sys debug], not because they never thought of it, they really don't need it.) And the back-up programs, what a joke, a complete and utter joke compared to dump/restore on 4.2 (or is file system backup and retrieval just not important to 'commercial' sites.) Follow the suggested backup procedures in the administrators manual, now try to recover a lost file (not file system, just one file.) Ooops, gotta know the inode number... Oh yeah, what about file system quotas? Completely missing in SYSV (except for the filesize limit, better than nothing I guess.) Or, again, is avoiding filled file systems just not something of interest to 'commercial' environments. The administrator's manual suggests running a job several times a day to check user's usage (I guess that's if you still have room on the disk to run the program.) And unbundling everything useful is a real strong point (hey, don't worry about nroff bugs, you don't get nroff! bugs fixed.) Again, maybe I read this wrong, maybe what I don't understand about commercial sites is that they're too stupid to take something for free when they can pay extra for the same thing. Along the same lines, should I tell my users to use all the nifty graphics packages? Or as soon as they get them debugged are they gonna unbundle them? Should I project my budget to reflect paying unbundled prices for every piece of software on the system that my users will end up screaming for? If unbundled nroff is here, can 'cat' be far behind? How about the accounting package, backup software, editors, mail system, make, sccs, games (what games?), shl, help, terminfo, cpio, debuggers (what debuggers?), C, f77.... I think price predictability is of some importance to a commercial market. Yeah, I know, how are they gonna make a living (poor AT&T.) On the other hand, as I said when DEC handed me the same line about VMS utilities (which are obscenely unbundled), ok, make a living off me not buying the whole system then, if that's your plan. I believe I have pretty much killed the idea of VMS workstations on this campus for that reason. Now what am I gonna have to say about a 3B2 to remain consistent? A -v arg to cat so it doesn't screw your terminal and a -C arg to ls so you have a chance to to actually see more than 20 files, I can understand your objections, but don't you think my list is a *little* more important....honestly? (maybe that's what you meant.) Ok, I *do* have a lot of faith in AT&T, I actually think as fast as you are playing apologist they are filling in the gaps, I have heard very solid rumours of a joint effort between AT&T and a 4.2 developer to just finish the gap between the two once and for all. R2 was a huge improvement over R1, I am very optimistic, and following SYSV right into the whole 'phone system as network' technology coming up from AT&T should be very exciting (not that 4.4BSD won't also have this :-) They shouldn't be afraid to write 'unsupported' or 'not yet supported' on a man page, it's a lot better than living without a feature for most of us (probably not on a dump utility, but how about a csh or other handy redundancies.) Don't misunderstand me, I'll take SYSV over anything on the market... except 4.2. Hey, maybe B.U. just isn't a commercial site and doesn't understand? But we have 2 3081s, a 4341, 19 vaxes, a 2060, 3B5, 3B2s etc etc, a lot of the strategy recomendations come out of this office...do we count too? How much of it is UNIX? not enough. I think you asked for this. I also think too much of this appeared to be pointed at you, this is actually a much broader shot. -Barry Shein, Boston University P.S. I may have made some small technical errors in my examples, we've only had SYSV here a few months and R2 a couple of weeks (maybe you *can* get a file off a backup tape by name, I couldn't see how.) Let's try to stick to the big issues. P.P.S. Hopefully, those at ATT who feel attacked will take this all as constructive criticism and remember that *I* am the customer (and a relatively happy one.) P.P.P.S (this is getting obnoxious) Maybe it's time to form a good ATTUS (analagous to DECUS.) hi doug, you're the only one who got this far.
hutch@sdcsvax.UUCP (Jim Hutchison) (07/22/85)
In article <371@cuae2.UUCP> heiby@cuae2.UUCP (Ron Heiby) writes: >There there, John. I was talking about the University of CA at Berkeley. >I was not talking about any commercial vendors. I have no knowledge of >Sun's quality control, although I have heard good reports from users >of Sun systems. BTW, in my previous job, I used a commercial port of >System III to a M68000 based system. The quality on that product was >marginal. So, I know enough not to be talking about quality of commercial >products based only on their porting base (although I have my favorite). Sir, BSD's spring from the loins of version 7. System V is of system III, hint think death star. :-) -- /* Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: hutch@sdcsvax [ Of course, these statements were typed into my terminal while I was away. ] */
b-davis@utah-cs.UUCP (Brad Davis) (07/22/85)
In our HP-UX 2.0 (a SYS3 port to HP 9000 S200) the following program
crashes the operating system with a
panic error: out of swap space
main()
{
while (malloc(1024)) ;
}
Don't have any problem with our BSD 4.2 1/2 Vax though.
(HP says it will be fixed in the next release that we
don't have yet.)
--
Brad Davis
{ihnp4, decvax, seismo}!utah-cs!b-davis
b-davis@utah-cs.ARPAgwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/22/85)
> >> There are also plenty of examples where AT&T adds a BSD feature, > >> but changes the command or system call name or syntax. Isn't that > >> referred to as the NIH (Not Invented Here) syndrome? When will AT&T > >> (and DEC for that matter) realize that UC Berkeley is NOT a competitor? > > > >There may be some "NIH" syndrome at work, but you should also appreciate > >that BSD software is not necessarily up to commercial standards, so it > >might need some adaptation before being supported by a commercial outfit. > > Ok Doug, it's fighting time. ... Hey, Barry, all I was saying is that it isn't a crime for AT&T to change some aspects of the code that they borrow from 4BSD when they integrate it into their product. I agree that there have been some very stupid decisions made in the UNIX System V packaging as well as some good ones. I am glad that they're making an effort to organize the UNIX package. I agree that there is no real networking (by Internet standards) in the AT&T product yet. TCP/IP is long overdue, but it is certainly not the ideal. AT&T has promised full ISO protocols implemented with streams, and have demonstrated a prototype full-semantics (unlike NFS) transparent remote filesystem which is expected to appear in their product "soon". I don't have 3Bs, so I don't know why you're having problems with the SGS. Our DMD SGS works fine. I thought flexnames were a standard feature now. Ptys should appear along with stream I/O, where they can be done right. The 4.2BSD "fast file system" is unnecessarily complex; AT&T is rumored to have a simple implementation of a fast file system. I don't know whether it fragments big blocks. It is funny that you take AT&T to task for providing "fsdb" and fault them for not providing other things.. 4.2BSD backup and restore is certainly an improvement over old tools. To their credit, AT&T has been improving many of the system administration procedures. Perhaps they will pick up on this one. The right way to implement file system quotas is subject to debate. I have been burned by the 4.2BSD scheme, which has some real lossages.. Unbundling is a sore point. Seems that what is really needed is a way for VARs/OEMs to sell packaged systems for minimal licensing fees, while end-users get a "rich" set of utilities in their basic package, in order to ensure that they have what is needed to support add-on software. I think the main problem is that AT&TIS sees themselves in the "iron" (computer hardware) business, not the information business. I hope they can see that UNIX is much more than just a 3B operating system. I note that they're dropping the VAX from future releases; is DEC going to fill in for them or are they going to keep Ultrix a 4BSD look-alike (or both)? The PWB/Graphics and Plot facilities are scheduled to be replaced by something else, probably based on GKS. Specs have not yet been published. I don't have any real stake in "playing apologist" for AT&T. I too have chastised them publicly for their mistakes. I do think, however, that there are better performance metrics than the degree to which they lift pieces of 4BSD unmodified. I hope the rumors of convergence between 4.nBSD and System V are true; otherwise, 4BSD's days are numbered. I've been doing my bit to help bring about such a merger, which does not necessarily mean that there would not continue to be two distinct systems for the different target user populations (research vs. commercial). The biggest roadblock to 4.nBSD migrating in a System V direction seems to have been the silly policy that AT&T now has of not permitting exchange of UNIX-derived software among source UNIX licensees who have different CPU types. I agree fully with AT&T's position that there should not be two flavors of standard shell. It looks like the Korn shell may filter into the AT&T product (other than as a ToolChest add-on); if so, there would be little reason to ask for a Cshell. Ksh is very nice, is Bourne shell compatible, and does everything the Cshell can do. An AT&T UNIX user's group that could exert pressure for wanted goodies might be a good idea. The existing UNIX groups do not seem to fulfill this role. > hi doug, you're the only one who got this far. Hi, Barry! Let's hope the AT&T UNIX policy makers are listening, too.
faustus@ucbcad.UUCP (Wayne A. Christopher) (07/23/85)
> > There are also plenty of examples where AT&T adds a BSD feature, > > but changes the command or system call name or syntax. Isn't that > > referred to as the NIH (Not Invented Here) syndrome? When will AT&T > > (and DEC for that matter) realize that UC Berkeley is NOT a competitor? > > There may be some "NIH" syndrome at work, but you should also appreciate > that BSD software is not necessarily up to commercial standards, so it > might need some adaptation before being supported by a commercial outfit. Oh sure, we can't have functions called "index" and "rindex". That's definitely not up to commercial standards -- we have to have them called "strchr" and "strrchr"... Fixing bugs is fine, but it's not usually necessary to make the stuff incompatible to make it work. * > Unfortunately, AT&T has been picking up some of the WORST features from > BSD. cat -v, ls -[a-z][A-Z], yuck. I don't know who is holding a gun to your head and making you type "cat -v", or maybe tying you up and making you watch 'while 1 man ls', but I wouldn't call these BSD's "worst features"... Wayne * Don't flame me if the index/strchr difference isn't an example of NIH -- I haven't used V5 much...
henry@utzoo.UUCP (Henry Spencer) (07/23/85)
Come now, nobody said AT&T's stuff didn't have bugs, just that Berkeley was worse. Which even some long-live-Berklix independents openly admit. If you caught Clem Cole's discussion of software distribution at Masscomp in the panel discussion at Usenix, you may have noted that he said there was often a quandary about which version of a utility to pick: the one from AT&T usually has more bugs fixed, while the one from Berkeley often runs faster. > And which file system is up to commercial standards? I think I have a > lot more faith in 4.2 than the SYSV 4.1 clone (how come 4.2 sites don't > even have an 'fsdb' [file sys debug], not because they never thought of > it, they really don't need it.) fsdb dates back to the days when *no* Unix filesystem was reliable, and the automatic repair algorithms in fsck didn't exist. Its existence in SysV is more likely to be a relic of the past than a real reflection of need, since even the V7 file system essentially never needed patching given fsck. (I speak as the sys admin of a V7 site, by the way.) > Oh yeah, what about file system quotas? Completely missing in SYSV > ... Or, again, > is avoiding filled file systems just not something of interest to > 'commercial' environments... The lack of file system quotas probably reflects AT&T's openly-expressed view (which I agree with) that except in special situations, if you think you need disk quotas then you really need more disks instead. Situations involving hostile users, e.g. undergrads, are obviously an exception -- note that this was the original motive for the 4.2 implementation of quotas -- but how many businesses have that problem? > And unbundling everything useful is a real strong point... As many people have pointed out, unbundling (a) is a botch, and (b) is necessary if you are selling Unix boxes with small disks. Not everybody has Eagles to put it all on. Whether AT&T's unbundling strategy is rational, even given this excuse, is another question... but it is not totally without reason. > ... maybe what I don't understand about commercial sites is > that they're too stupid to take something for free when they can pay > extra for the same thing... Pray tell, how can a binary-only licensee (most commercial sites do not have source, remember) get these things for free? I know quite a few binary-only sites that would love to know. > A -v arg to cat so it doesn't screw your terminal and a -C arg to ls so > you have a chance to to actually see more than 20 files, I can > understand your objections, but don't you think my list is a *little* > more important....honestly? Since I think both cat -v and ls -C are botches, I agree. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
tom@tommif.UUCP (Tom Faulhaber) (07/24/85)
In article <2453@sun.uucp>, guy@sun.uucp (Guy Harris) writes: > > > By implication that puts all commercial vendors of 4.2BSD systems > > > in the "unstable computing environment business"? > My machine is supplied by a "commercial vendor of 4.2BSD systems" (as is > John's, I suspect :-) :-) :-)), and, well, > > 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00 > > (etc.) I am afraid that this is the point that proves the argument. We have an Ethernet composed of Convergent MiniFrames (the parent of the PC 7300) in Un*x engineering at CT. A few days ago an ruptime display would have shown you that the Networking development machine (mine) and the OS development machine had been up for 45 days. These machines had rebooted after PG&E decided to run over one of the power lines to our building. Unfortunately last week they ran over the power lines again! I would note that the OS development machine was running the latest CTIX version, and the networking machine was running an experimental kernel. I say this only partially to brag about our systems. Primarily, I would like point out that five or even fifteen days of uptime does not make a solid operating system. Tom Faulhaber ...decwrl!greipa!tommif!tom P.S. Of course, we run System V.
westerm@ecn-aa.UUCP (Westerman) (07/24/85)
In article <514@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: > >P.P.P.S (this is getting obnoxious) Maybe it's time to form a good >ATTUS (analagous to DECUS.) > Yes, let's form ATTUS. As I see it, AT&T is our only hope to get UNIX out of being a much talked about OS into being a much used OS. Whom: Rick Westerman Phone: +1-317-494-8344 UUCP: {decvax, ihnp4, seismo, ucbvax}!pur-ee!westerm USPS: Ag Data Network, Purdue University, West Lafayette IN 47907 A proud owner of a 3b2, but a *user* of 4.2 ---> "4.2 > V"
peter@baylor.UUCP (Peter da Silva) (07/24/85)
> > By implication that puts all commercial vendors of 4.2BSD systems > > in the "unstable computing environment business"? > > Judging by how often we find bugs and our machines crash, I'd say yes, > runnning 4.2 BSD is being in an unstable computing environment. Judging by how much stuff Bell broke when they came out with SV, and judging by the fact that BSD is still sufficiently compatible that you can run a V6 binary on it (2BSD, but 2 is source compatible with 4), even if it uses stty, I'd say it's Bell that's in the unstable computing environment business. System III. System V, consider it standard. System V, release 2, from now on consider it standard. System V, release 2, Version 2? -- -- Peter da Silva (the mad Australian) -- UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter -- ARPA: baylor.peter@RICE.ARPA -- MCI: PDASILVA; CIS: 70216,1076; DELPHI: PJDASILVA --
campbell@maynard.UUCP (Larry Campbell) (07/25/85)
> The lack of file system quotas probably reflects AT&T's openly-expressed > view (which I agree with) that except in special situations, if you think > you need disk quotas then you really need more disks instead. Situations > involving hostile users, e.g. undergrads, are obviously an exception -- > note that this was the original motive for the 4.2 implementation of > quotas -- but how many businesses have that problem? Hostile users aren't the only good reason to have quotas. What about buggy software that gets into an infinite loop writing to a file? It's pretty annoying that such a bug can essentially crash (i.e., make useless) a timesharing system. > As many people have pointed out, unbundling (a) is a botch, and (b) is > necessary if you are selling Unix boxes with small disks. Not everybody > has Eagles to put it all on... I thought unbundling was done mainly to reduce the entry-level price of a Unix license. After all, you could always ship everything and let the user decide which pieces to devote disk space to. (And I agree -- unbundling is a botch.) > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Larry Campbell decvax!genrad The Boston Software Works, Inc. \ 120 Fulton St. seismo!harvard!wjh12!maynard!campbell Boston MA 02109 / / ihnp4 cbosgd ARPA: decvax!genrad!wjh12!maynard!campbell@DECWRL.ARPA
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/25/85)
> System III. UNIX 3.0 > System V, consider it standard. UNIX 5.0 (4.0 was not released for public licensing) > System V, release 2, from now on consider it standard. UNIX 6.0, until AT&T decided to establish "UNIX System V" as a recognized symbol. Now UNIX 5.2 > System V, release 2, Version 2? This has been a remarkably upward-compatible evolutionary path. 5.2.2 added demand paging (much cleaner than 4BSD's) and record locking (more general than either 4BSD or /usr/group) without visibly changing the semantics of already-existing facilities. This is the way it should be. Both 4BSD and UNIX System V have good and bad points and both have unnecessarily broken things in new releases. The main advantage of System V (notice that "UNIX" is omitted here) with regard to stability is that all significant commercial UNIX and C standardization efforts are adhering closely to it (and vice-versa). Could we go on to more productive topics?
henry@utzoo.UUCP (Henry Spencer) (07/25/85)
> * Don't flame me if the index/strchr difference isn't an example of NIH -- > I haven't used V5 much... I'd be suprised if you had, since V5 means "Version 5", which was a Bell Labs (not USG) Unix around 1974. If you mean "System V", please say it that way -- they are not the same thing. "Calling System V `V5'?!? Them's fightin' words, bub!" -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
guy@sun.uucp (Guy Harris) (07/26/85)
> Sir, BSD's spring from the loins of version 7. System V is of system III, > hint think death star. :-) Umm, err, V7 also came out of the death star, although it came from a different place therein. S3 came from a slightly pre-V7 release (*much much* closer to V7 than to V6). Then again, you can't hold AT&T (from whose code *all* the aforementioned UNIXes ultimately derives) responsible for what other people do to it when bringing it up on their machines, so his S3 problems may have had nothing to do with S3 as it came out of AT&T. Guy Harris
guy@sun.uucp (Guy Harris) (07/26/85)
> > 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00 > > > > (etc.) > > I am afraid that this is the point that proves the argument. Bull. Absence of evidence is not evidence of absence. If you mean that the "uptime" listing there proves that 4.2BSD systems can't stay up more than 5 days, it's time to take a course in reasoning. All it proves is that "sun" (a machine which has had its share of hardware problems) had been up for 5 days at the time I type "uptime" at it. The last time I bounced my own machine, it was because it hung when I tried to exit the window system - this could have been the fault of the window system (not 4.2BSD code), the shell I'm running (an S5R2 Bourne shell with *lots* of hacks thrown into it), or a number of other programs whose problems you couldn't blame on Berkeley. > Primarily, I would like point out that five or even fifteen days of uptime > does not make a solid operating system. OK. Now I'll point out that frequent crashes/reboots does not make a flaky operating system (I suspect hardware problems cause most of the trouble around here). > P.S. Of course, we run System V. With, I believe, 4.1BSD memory management code (unless you've dropped the S5R2V2 code in) and possibly 4.2BSD (or 4.1aBSD or 4.1cBSD) networking code (the use of "ruptime" in your message gives a possible hint). As such, the fact that CTIX stayed up on one particular machine for 45 days doesn't say much about the reliability of System V vs. 4.xBSD.
guy@sun.uucp (Guy Harris) (07/26/85)
> ...a quandary about which version of a utility to pick: the one > from AT&T usually has more bugs fixed, while the one from Berkeley often > runs faster. Which means, if the utility is important enough that it's worth the work, the best strategy might be to "diff" the suckers and take the best from both and put it into one version. (There is one utility where the one from AT&T runs faster, and the one from Berkeley has more bugs fixed - "awk". The S5R2 "awk" is quite a bit faster than all previous "awk"s, including the 4.2BSD one - one change is that it no longer uses structure-valued arguments and functions - but it still has null-pointer-dereferencing bugs. We beat those out of the 4.2BSD one...) (Then again, there are those utilities where the only difference is the formatting of the code, or the presence, absence, or shape of an SCCS ID - yes, there *are* utilities that haven't changed since V7, as I know you're aware, but some people might be shocked to hear that, especially the people who don't think AT&T had anything to do with Berkeley UNIX...) > The lack of file system quotas probably reflects AT&T's openly-expressed > view (which I agree with) that except in special situations, if you think > you need disk quotas then you really need more disks instead. Maybe yes, maybe no. I think Parkinson's Law applies to disk space as well; give users more disk space and they'll find some way to fill it, even if they just fill it with "net.politics" archives. Think of it as an economic problem; you have a scarce resource, but the price mechanism has a long time-scale over which it works - possibly too long to prevent short-term space shortages. Quotas can keep users from eating the disks until you can buy new ones, or until their managers get the bill for their disk space and say "delete something or else". I'd be curious to know how many commercial VMS sites, say, use the VMS disk quota mechanism? We've started to use disk quotas here; we frequently have space problems. We had them at CCI as well. CCI's customers also had them; our office automation systems were often sold to people who weren't necessarily experienced system administrators, and who may not really think about the fact that every big document they keep around represents a document that some other user can't keep around. Again, there are administrative techniques that can control disk usage over the long term, but quotas can help deal with shortages in the short term. > As many people have pointed out, unbundling (a) is a botch, and (b) is > necessary if you are selling Unix boxes with small disks. Not everybody > has Eagles to put it all on. Whether AT&T's unbundling strategy is > rational, even given this excuse, is another question... but it is not > totally without reason. There's a difference between unbundling and charging separately; you can provide a basic utility set and additional utilities as a single package, or you can sell the additional utilities as add-ons. I believe it is the latter policy that people object to. This policy is not a solution to the technical problem of not having enough disk space to store all UNIX utilities; it is a solution to the economic problem of paying for the development and maintenance of software without charging people who have no use for that software. Guy Harris
cs1@oddjob.UUCP (Cheryl Stewart) (07/26/85)
Is there a place where the differences between sysV and 4.2 are documented? (please don't tell me "sure, diff the sources of both!" I'm no sorcerer.) ihnp4!oddjob!cs1 --
guy@sun.uucp (Guy Harris) (07/27/85)
> Judging by how much stuff Bell broke when they came out with SV, and > judging by the fact that BSD is still sufficiently compatible that you > can run a V6 binary on it (2BSD, but 2 is source compatible with 4), "V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6 (I think 1BSD was the V6 Berkeley distribution), but, more importantly, you *can't* run V6 binaries on V7. You don't even have a good chance of compiling *source* written for V6 on a V7 system and having it run. And there are programs written for V7 that will break when you try to compile them and run them under 4.2BSD... > even if it uses stty, I'd say it's Bell that's in the unstable computing > environment business. If you're referring to the S3 terminal driver, from Bell's standpoint they didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or whatever the hell the release before UNIX 3.0 was). The trouble is that the release that went out the door before System III was V7, not UNIX 2.0, which means the S3 driver's backward compatibility with UNIX 2.0 is totally useless to anybody outside the former Bell System. Guy Harris
guy@sun.uucp (Guy Harris) (07/27/85)
> > * Don't flame me if the index/strchr difference isn't an example of NIH -- > > I haven't used V5 much... > > I'd be suprised if you had, since V5 means "Version 5", which was a Bell > Labs (not USG) Unix around 1974. If you mean "System V", please say it > that way -- they are not the same thing. Furthermore, the index/strchr difference is probably not an example of NIH in the way the original poster thought. *Both* routines are products of AT&T - the routine was called "index" in V7 and "strchr" in System III. At what point it was renamed, I dunno. The S3 documentation comes with a description of changes between S3 and some unspecified earlier version of UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This predates V7, since it was called "strncpy" there as well. Guy Harris
roy@phri.UUCP (Roy Smith) (07/27/85)
> ... I think both cat -v and ls -C are botches ... > Henry Spencer @ U of Toronto Zoology Why is "cat -v" a botch? If you want to see if you have junk in a file it's a lot nicer than "od -c". And what's so terrible about "ls -C"? The multi-column format is much nicer, and it turns out that most of the time it does the right thing (i.e. picks 1-column vs. multi-column mode). Oh, BTW, for you net.micro.att readers, note that I've added a Followup-To: net.unix-wizards line. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
jsq@im4u.UUCP (07/27/85)
Some of you may be amused by running the following figure through pic
and ditroff (after extracting it with sh). I make no claims as to its
accuracy or completeness.
(By the way, I've added "Followup-To: net.unix" to the header lines.)
: This is a shar archive. Extract with sh, not csh.
echo x - history.pic
sed -e 's/^X//' > history.pic << '!RoNnIe!RaYgUn!'
X.\" pic -Pip history.pic | ditroff -Pip
X.ps -2
X.PS
Xsmallb = 0.5i
Xmedb = 0.75i
Xbigb = 1i
Xbiggerb = 1.5i
Xboxwid = smallb
Xboxht = smallb / 2
Xmovewid = 0.5i
X
Xspacing=0.5i
Xsysv=spacing
Xmert=sysv + spacing
Xpwb=mert + spacing
Xcbunix= pwb + spacing
Xresearch=cbunix + spacing
Xv32=research + spacing
Xbsd4=research + (2 * spacing)
Xbsd2=bsd4 + spacing
X
Xboxwid = medb
XD69: box invis "1969"
XD73: box invis "1973"
Xboxwid = smallb
XD76: box invis "1976"; move
XD77: box invis "1977"; move
XD78: box invis "1978"; move
XD79: box invis "1979"; move
XD80: box invis "1980"; move
XD81: box invis "1981"; move
XD82: box invis "1982"; move
XD83: box invis "1983"; move
XD84: box invis "1984"; move
XD85: box invis "1985"
XLabel: box invis at D69
X
Xboxwid = smallb
XV1: box invis "V1" at D69 + (0, research)
XV5: box invis "V5" at D73 + (0, research)
XV6: box invis "V6" at D76 + (0, research)
Xboxwid = bigb
XV7: box "Version 7" at D78 + (0, research)
Xarrow from V1.e to V5.w
Xarrow from V5.e to V6.w
Xarrow from V6.e to V7.w
X
Xboxwid = smallb
XV32: box invis "32V" at 1/4 <D78, D79> + (0, v32)
Xboxwid = bigb
XV8: box "Version 8" at D83 + (0, v32)
Xarrow from V7.n to V32.s
Xarrow from V32.e to V8.w
Xarrow right from V8.e
X
X"\fIBell Research\fP" ljust at Label + (0, research + (v32 - research) / 2)
X
Xboxwid = smallb
XPWB: box invis "PWB" at 1/2 <V6, V7> + (0, pwb - research)
Xarrow from V6.s to PWB.nw
XU30: box invis "3.0" at 1/2 <D79, D80> + (0, pwb)
Xarrow from V32.se to 4/5 <PWB, U30>
Xarrow from V7.sw to 1/2 <PWB, U30>
XU40: box invis "4.0.1" at D81 + (0, pwb)
XU301: box invis "3.0.1" at 1/2 <U30, U40>
XU50: box invis "5.0" at D82 + (0, pwb)
XU52: box invis "5.2" at D83 + (0, pwb)
XU524: box invis "5.2.4" at D84 + (0, pwb)
Xarrow from PWB.e to U30.w
Xarrow from U30.e to U301.w
Xarrow from U301.e to U40.w
Xarrow from U40.e to U50.w
Xarrow from U50.e to U52.w
Xarrow from U52.e to U524.w
Xarrow right from U524.e
X
Xboxwid = bigb
XCBUNIX: box invis "CB UNIX" at PWB + (0, cbunix - pwb)
Xarrow from 1/4 <V6, V7> to CBUNIX.n
Xspline -> from CBUNIX.e to U301 + (0, cbunix - pwb) then to 1/2 <U301, U40>
X
X"\fIBell Columbus\fP" ljust at Label + (0, cbunix)
X
Xboxwid = medb
XMERT: box invis "MERT" at PWB + (0, mert - pwb)
Xboxwid = bigb
XUNIXRT: box invis "UNIX/RT" at D78 + (0, mert)
Xarrow from V6.s to MERT.nw
Xarrow from MERT.e to UNIXRT.w
Xarrow from UNIXRT.ne to 3/4 <PWB, U30>
X
Xboxwid = bigb
XSysIII: box "System III" at D82 + (0, sysv)
XSysV: box invis "System V" at D83 + (0, sysv)
Xoldht = boxht
Xboxht = oldht * 2
XSysV2: box "System V" "Release 2" at D84 + (0, sysv)
Xboxht = oldht * 3
XSysV24: box dotted "System V" "Release 2" "Version 4" at D85 + (0, sysv)
Xboxht = oldht
Xarrow from U301.se to SysIII.n
Xarrow from U50.se to SysV.n
Xarrow from U52.se to SysV2.n
Xarrow from U524.se to SysV24.n
X
X"\fIUSG / USDL\fP" ljust at Label + (0, sysv + (pwb - sysv)/2)
X
Xboxwid = smallb
XBSD3: box invis "3BSD" at 1/2 <D78, D79> + (0, bsd4)
Xarrow from V32.n to BSD3.s
Xboxwid = medb
XBSD40: box invis "4.0BSD" at 1/2 <D79, D80> + (0, bsd4)
XBSD41: box "4.1BSD" at 1/2 <D80, D81> + (0, bsd4)
XBSD42: box "4.2BSD" at 1/2 <D83, D84> + (0, bsd4)
XBSD41A: box invis "\s-14.1aBSD\s0" at 1/3 <BSD41, BSD42>
XBSD41C: box invis "\s-14.1cBSD\s0" at 2/3 <BSD41, BSD42>
XBSD43: box dotted "4.3BSD" at 1/2 <D84, D85> + (0, bsd4)
Xarrow from BSD3.e to BSD40.w
Xarrow from BSD40.e to BSD41.w
Xarrow from BSD41.e to BSD41A.w
Xarrow from BSD41A.e to BSD41C.w
Xarrow from BSD41C.e to BSD42.w
Xarrow from BSD42.e to BSD43.w
Xarrow right from BSD43.e
X
Xarrow from 1/5 <V32, V8> to BSD41.sw
X
Xboxwid = smallb
XBSD1: box invis "1BSD" at 1/2 <V6, V7> + (0, bsd2 - research)
XBSD2: box invis "2BSD" at V7 + (0, bsd2 - research)
Xboxwid = medb
XBSD28: box invis "2.8BSD" at D82 + (0, bsd2)
XBSD29: box invis "2.9BSD" at D83 + (0, bsd2)
Xarrow from V6.n to BSD1.s
Xarrow from BSD1.e to BSD2.w
Xarrow from BSD2.e to BSD28.w
Xarrow from BSD28.e to BSD29.w
Xarrow right from BSD29.e
X
Xarrow from BSD2.s to BSD3.n
Xarrow from BSD41.ne to BSD28.sw
Xarrow from 1/2 <BSD41A, BSD41C> to BSD29.sw
X
X"\fIBerkeley\fP" ljust at Label + (0, bsd4 + (bsd2 - bsd4)/2)
X
Xarrow from BSD41.se to 3/4 <V32, V8>
Xarrow from BSD41.s to U50.n
X
Xboxwid = medb
Xbox dashed "PDP-11" at BSD1 + (-1, 0)
Xboxwid = smallb
Xbox dashed "VAX" at 1/2 <V32, BSD3> + (-1, 0)
Xboxwid = medb
Xbox dashed "PDP-11" at PWB.w + (-1, 0)
Xboxwid = biggerb
Xbox dashed "PDP-11 / VAX" with .ne at 1/2 <U30, SysIII>
X
X.PE
X.ps +2
!RoNnIe!RaYgUn!
exit
--
John Quarterman, UUCP: {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET: jsq@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDUtim@cithep.UucP (Tim Smith ) (07/28/85)
I disagree with your statement that fsdb is not really needed because of
fsck. There are problems that fsck refuses to deal with, for example,
an unallocated root inode. Fsdb is very handy in this case. Also,
possible file size errors are reported by fsck, but nothing is done with
them. Fsdb is very useful here. You can look at the inode, figure out
what the size should be ( actually, I have a program to do this part... ),
and set the size in the inode. And how about trashed superblocks?
Also, I have noticed that if an ordinary file overwrites a directory,
fsck tends to core dump on that filesystem.
--
Tim Smith
ihnp4!{wlbr!callan,cithep}!timmark@cbosgd.UUCP (Mark Horton) (07/28/85)
In article <2503@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> Judging by how much stuff Bell broke when they came out with SV, and >> judging by the fact that BSD is still sufficiently compatible that you >> can run a V6 binary on it (2BSD, but 2 is source compatible with 4), > >"V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6 >(I think 1BSD was the V6 Berkeley distribution), but, more importantly, you >*can't* run V6 binaries on V7. You don't even have a good chance of >compiling *source* written for V6 on a V7 system and having it run. Surprise, Guy, but 4.2BSD really CAN run many V6 binaries. For example, look at /usr/games/lib/dungeon and /usr/games/lib/chess, which are invoked by /usr/games/zork and /usr/games/chess, respectively. I've also copied some other V6 style binaries over and run them successfully. However, this is misleading. In the first place, dungeon is really an RSX-11 binary (from a Fortran source) which was munged into a V6 binary which was in turn munged into a V7 binary (the differences between V6 and V7 binaries really aren't that great), and chess is really a V7 binary. In the second place, what's really happening here is that these binaries are PDP-11 binaries (that's what V6 and V7 ran on) which are run in VAX compatibility mode (the VAX hardware supports such a thing) using a program called /usr/games/lib/compat and a front end to open the files. The hardware does not support split I/D, and of course this only works on a VAX, not on a Sun or other 4.2BSD machine (where you won't find zork or chess.) In the third place, there are several incompatibilities between 4.2BSD and earlier releases of UNIX, such as 4.1BSD, 3BSD, V7, and V6. Most of these compatibilities are at the source level, so if you can get past the compiler, a lot of things are simpler. Nonetheless, most V7 programs will compile and run happily on 4BSD, which is not true of System V.
clyde@ut-ngp.UTEXAS (Clyde W. Hoover) (07/29/85)
>> Judging by how much stuff Bell broke when they came out with SV, and >> judging by the fact that BSD is still sufficiently compatible that you >> can run a V6 binary on it (2BSD, but 2 is source compatible with 4), >"V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6 >(I think 1BSD was the V6 Berkeley distribution), but, more importantly, you >*can't* run V6 binaries on V7. You don't even have a good chance of >compiling *source* written for V6 on a V7 system and having it run. Sorry Guy, I've got some V6 binaries that run just fine under 2.9BSD (The sources were lost a LONG time ago). As long as you stick to basic UNIX system calls (e.g. 'open', 'close', 'fork', 'read' and 'write'), in a '407' executable, there is no essential system interface difference between V6 and V7 or 2.XBSD. And except for VAX-related braindamage, I have easily gotten code from V7/2.8/2.9 systems to compile & run under 4.1c/4.2BSD. (Suns are another matter - much like the VAX but without some of the stranger braindamage). -- Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas "Forward my mail to the corner of Pork and Beans" clyde@ut-ngp.ARPA, clyde@ut-sally.ARPA ...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde
mash@mips.UUCP (John Mashey) (07/29/85)
Guy Harris writes (onto long sequence of articles): > > > * Don't flame me if the index/strchr difference isn't an example of NIH -- > > > I haven't used V5 much... > > Furthermore, the index/strchr difference is probably not an example of NIH > in the way the original poster thought. *Both* routines are products of > AT&T - the routine was called "index" in V7 and "strchr" in System III. At > what point it was renamed, I dunno. The S3 documentation comes with a > description of changes between S3 and some unspecified earlier version of > UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This > predates V7, since it was called "strncpy" there as well. 0) As usual, Guy has pretty good model of the history, minor details: 1) index->strchr happened in UNIX/TS 1.0 (in some sense, System I of the System V sequence). My 1.0 manual reads November 78; as I recall, this particular change happened fairly early in the packaging effort that was trying to get Edition 7 (late, but not released), PWB/UNIX 1.2, and some USG G3 UNIX all back together. 2) strcpyn ->strncpy happened at the same time, early 78. The rename was because some non-UNIX systems (GCOS, I think) took only the first 6 characters, so that strcpy and strcpyn conflicted, a clearly bad thing. 3) In general, it is unwise to EVER label something as NIH unless you know for a fact that it is NIH. There are more weird reasons for things being different in different UNIX versions than you would ever believe; only a few of them are NIH; it is always best to ask why things are different. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
mash@mips.UUCP (John Mashey) (07/29/85)
> > even if it uses stty, I'd say it's Bell that's in the unstable computing > > environment business. > > If you're referring to the S3 terminal driver, from Bell's standpoint they > didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or > whatever the hell the release before UNIX 3.0 was). The trouble is that the > release that went out the door before System III was V7, not UNIX 2.0, which > means the S3 driver's backward compatibility with UNIX 2.0 is totally > useless to anybody outside the former Bell System. 1) PWB/UNIX 2.0 was the release before, and before that was UNIX/TS 1.0 (Nov 78). Both of these still had stty/gtty in section (2), with ioctl(3), with everybody warned to switch over. 2) It is always worth remembering: a) Research versions of ANYTHING have no commitment whatsoever to upward compatibility (whether from ATT, UCB, or anywhere else). Once they do that, the research content falls off pretty badly. Back in the real old days when we got releases straight from 127, we were happy when something was upward compatible, but certainly didn't expect it. b) Supported versions that do have such commitments must play by radically different rules, which make them take longer to do: 1) Worry about major customers [for example, as I recall, the ioctl stuff came from CB/UNIX, or Operations Systems Unices in general, because the V6/V7 stuff wasn't quite enough. Remember that such Unices paid the bills for a long time. 2) Never add anything that you not sure of lasting for a while, because you do have the commitment to keep it semi-forever. 3) Work very hard on transition aids and strategies. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
henry@utzoo.UUCP (Henry Spencer) (07/29/85)
> Which means, if the utility is important enough that it's worth the work, > the best strategy might be to "diff" the suckers and take the best from both > and put it into one version. Also important is to take the worst from both and *not* put it into the new version. > > The lack of file system quotas probably reflects AT&T's openly-expressed > > view (which I agree with) that except in special situations, if you think > > you need disk quotas then you really need more disks instead. > > ...Think of it as an economic > problem; you have a scarce resource, but the price mechanism has a long > time-scale over which it works - possibly too long to prevent short-term > space shortages. Quotas can keep users from eating the disks until you can > buy new ones... The AT&T observation was not that there is no reason for quotas, but that (like password aging) they don't work satisfactorily. If you can *impose* quotas on your user community, you can make them work. If users can argue with the quotas, then you're sunk, because the sum total of the quotas that users feel they can live with probably exceeds the size of the disk. That is, if disk space is short enough that you *need* quotas, it's probably overcommitted already. My own experience with space-short systems certainly supports this claim. There is also the related problem of maxima becoming minima: "I'm under my quota, so I don't need to clean up yet". I have no personal experience with quota systems, but I really wonder if they aren't like password aging: a superficially-plausible idea that doesn't really work all that well. Hostile users are another story, of course. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/30/85)
> Is there a place where the differences between sysV and 4.2 are > documented? All such lists that I've seen, including internal documents of vendors, have been quite incomplete. There really seems to be little point in such a list, unless you're a UNIX package vendor. Only people who specialize in this topic are likely to be able to remember most of the differences. The good news is, that you can develop applications under the System V environment in such a way that they will run unmodified on any 4.2BSD system having an appropriate compatibility package such as the BRL emulation. (Contact your vendor for availability of some such package.) There are a few constraints when you use this approach, but they are much less troublesome than trying to write code to a lowest common denominator or with enough #ifdefs to accommodate all flavors of UNIX.
friesen@psivax.UUCP (Stanley Friesen) (07/31/85)
In article <514@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: > >And the back-up programs, what a joke, a complete and utter joke >compared to dump/restore on 4.2 (or is file system backup and retrieval >just not important to 'commercial' sites.) Follow the suggested backup >procedures in the administrators manual, now try to recover a lost file >(not file system, just one file.) Ooops, gotta know the inode number... > Holy Cow! Is this really true! How revolting. I think you could retrieve a backed-up file by name even back in V7 days! Now my two cents worth on the general subject. We have almost never run into significant software related problems here, and we have been running vanill BSD 4.x for about 2 years. The closest we came was a flaky interaction between Massbus 2 and Massbus 0 which resulted in a hung tape drive periodically. Our vendor fixed this almost immediately. Other than this we have only had hardware problems - the perennial tbuf parity fault bit(which I think System V is also subject to), and the usual power failures and so on. seems like a stable system to me. -- Sarima (Stanley Friesen) {trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen
heiby@cuae2.UUCP (Ron Heiby) (07/31/85)
In article <133@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: >Hostile users aren't the only good reason to have quotas. What about >buggy software that gets into an infinite loop writing to a file? That's what "ulimit" is for. Don't use an SST when roller skates will do. -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
peter@kitty.UUCP (Peter DaSilva) (07/31/85)
> > And unbundling everything useful is a real strong point... > > As many people have pointed out, unbundling (a) is a botch, and (b) is > necessary if you are selling Unix boxes with small disks. Not everybody > has Eagles to put it all on. Whether AT&T's unbundling strategy is > rational, even given this excuse, is another question... but it is not > totally without reason. Venix comes with virtually all the utilities & runs on a PC-XT. That's a 10 megabyte disk, folks. Not an Eagle. That's not a reason, that's not even an excuse, that's just a rationalisation.
peter@kitty.UUCP (Peter DaSilva) (07/31/85)
> > 4:00pm up 5 days, 2:33, 6 users, load average: 0.23, 0.07, 0.00 > > > > (etc.) > > I am afraid that this is the point that proves the argument. We have > an Ethernet composed of Convergent MiniFrames (the parent of the PC 7300) > in Un*x engineering at CT. A few days ago an ruptime display would have > shown you that the Networking development machine (mine) and the OS development > machine had been up for 45 days. These machines had rebooted after PG&E > decided to run over one of the power lines to our building. Unfortunately last > week they ran over the power lines again! I would note that the OS > development machine was running the latest CTIX version, and the networking > machine was running an experimental kernel. > > I say this only partially to brag about our systems. Primarily, I would like > point out that five or even fifteen days of uptime does not make a solid > operating system. > > Tom Faulhaber We have an old LSI-11 running V7. Uptime is 49 days. I don't recall the last time it went down but I think it was because of a power failure. Before that the last reboot was in March when we replaced the flakey hard drive. I have no intention of ever getting a SV system if I can at all avoid it. I have too much software that Bell won't run because they used PWB as the basis for SIII instead of V7 (the last true UNIX). 4.2 is exceptionally compatible with V7... and the 4.2 system next door has proven itself reliable.
peter@kitty.UUCP (Peter DaSilva) (07/31/85)
> The main > advantage of System V (notice that "UNIX" is omitted here) > with regard to stability is that all significant commercial > UNIX and C standardization efforts are adhering closely to it > (and vice-versa). It is to laugh. Most real world UNIX systems are STILL descendents of V7.
peter@kitty.UUCP (Peter DaSilva) (07/31/85)
> Yes, let's form ATTUS. As I see it, AT&T is our only hope to get UNIX > out of being a much talked about OS into being a much used OS. I'd love to join a UNIX users group which doesn't have outrageous membership fees. Next question: who is going to implement it?
peter@kitty.UUCP (Peter DaSilva) (07/31/85)
> > [ME] > [Guy Harris] [ME] > > Judging by how much stuff Bell broke when they came out with SV, and > > judging by the fact that BSD is still sufficiently compatible that you > > can run a V6 binary on it (2BSD, but 2 is source compatible with 4), > > "V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6 I never said it wasn't. The V7 was an early 2BSD release. The V6 was vanilla V6 (the Berkeley comp center is terribly conservative. They still had one machine running V5!). > (I think 1BSD was the V6 Berkeley distribution), but, more importantly, you > *can't* run V6 binaries on V7. You don't even have a good chance of > compiling *source* written for V6 on a V7 system and having it run. I have run V6 binaries on V7. I was at berkeley when the V6/V7 switch was going on and this was the only way to get certain traditional programs for V7. We were also running an RSX (!) version of basic+, suitably patched. Source for V6 ran on V7 with very few problems (had to change RAW to CBREAK, that was about all). > And there are programs written for V7 that will break when you try to > compile them and run them under 4.2BSD... Yes, but it's a hell of a lot easier to fix them for 4.2 than for > > even if it uses stty, I'd say it's Bell that's in the unstable computing > > environment business. > > If you're referring to the S3 terminal driver, from Bell's standpoint they > didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or > whatever the hell the release before UNIX 3.0 was). The trouble is that the > release that went out the door before System III was V7, not UNIX 2.0, which > means the S3 driver's backward compatibility with UNIX 2.0 is totally > useless to anybody outside the former Bell System. And since V7 and derivatives is the most common UNIX in the real world... > Guy Harris Peter da Silva
peter@kitty.UUCP (Peter DaSilva) (07/31/85)
> > [ME] > [Guy Harris] [Me: second try at replying] > > Judging by how much stuff Bell broke when they came out with SV, and > > judging by the fact that BSD is still sufficiently compatible that you > > can run a V6 binary on it (2BSD, but 2 is source compatible with 4), > > "V6 binary"? What have you been smoking? For one thing, 2BSD is V7, not V6 I know. I was referring to the V7 system as 2BSD, not the V6 one. I know what 2- and 4- BSD are. Hell, some of my code went out in one of the releases (I've seen it at IUVAX). > (I think 1BSD was the V6 Berkeley distribution), but, more importantly, you > *can't* run V6 binaries on V7. You don't even have a good chance of > compiling *source* written for V6 on a V7 system and having it run. At Berkeley there were several V6 programs that there was no source to. They were running on a 2BSD system (ucbcory). QED. > And there are programs written for V7 that will break when you try to > compile them and run them under 4.2BSD... Actually once you change RAW to CBREAK they're quite compatible. I've moved stuff between V5, V6, and V7 with few problems. SIII and SV are a royal pain, though. > > even if it uses stty, I'd say it's Bell that's in the unstable computing > > environment business. > > If you're referring to the S3 terminal driver, from Bell's standpoint they > didn't break anything. It's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or > whatever the hell the release before UNIX 3.0 was). The trouble is that the > release that went out the door before System III was V7, not UNIX 2.0, which > means the S3 driver's backward compatibility with UNIX 2.0 is totally > useless to anybody outside the former Bell System. And since most real world UNICES are V7 derived, what does that say about Bell?
weh@druny.UUCP (HopkinsWE) (07/31/85)
With respect to the discussion about the change from stty(2) to ioctl(2), yes, stty is no longer included in official System V Release 2 documentation, but it is still there in the kernal (it calls ioctl). I ran into it while modifying some code, didn't find it in 5.2, 5.0, or 3.0 manual, then asked someone who had 4.2bsd background who recognized it and then tracked it down in the kernal. Bill Hopkins AT&T Information Systems ihnp4!druny!weh
jss@sjuvax.UUCP (J. Shapiro) (08/01/85)
> > ... I think both cat -v and ls -C are botches ... > > Henry Spencer @ U of Toronto Zoology > > And what's so terrible about "ls -C"? > Roy Smith <allegra!phri!roy> The only thing terrible about ls -C is that it ought to be the default for CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_ brain damaged. Jon Shapiro Haverford College
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/01/85)
> Most real world UNIX systems are STILL descendents of V7.
Must be an alternate universe (see net.physics).jww@sdcsvax.UUCP (Joel West) (08/01/85)
(in article <...> mark horton [you know who and where he is] writes) > However, this is misleading. In the first place, dungeon is really an RSX-11 > binary (from a Fortran source) which was munged into a V6 binary which was > in turn munged into a V7 binary (the differences between V6 and V7 binaries > really aren't that great), and chess is really a V7 binary. > > In the second place, what's really happening here is that these binaries are > PDP-11 binaries (that's what V6 and V7 ran on) which are run in VAX > compatibility mode (the VAX hardware supports such a thing) using a program > called /usr/games/lib/compat and a front end to open the files. Oh, oh. I'm no longer looking forward to getting my MicroVAX II (which I think has dumped PDP-11 once and for all). I won't be able to play zork! :-( [:-)] Joel West CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}!sdcsvax!jww jww@SDCSVAX.ARPA
roy@phri.UUCP (Roy Smith) (08/01/85)
What started out as (yet another) discussion about 4.2 vs. Sys5 has now turned to discussing disk quota systems. Since I would hate to see mod.unix die out, I have taken advantage of this change of topic and sent a followup article to mod.unix; see you all there. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
jlw@ariel.UUCP (J.WOOD) (08/02/85)
> Guy Harris writes (onto long sequence of articles): > > > > * Don't flame me if the index/strchr difference isn't an example of NIH -- > > > > I haven't used V5 much... > > > > Furthermore, the index/strchr difference is probably not an example of NIH > > in the way the original poster thought. *Both* routines are products of > > AT&T - the routine was called "index" in V7 and "strchr" in System III. At > > what point it was renamed, I dunno. The S3 documentation comes with a > > description of changes between S3 and some unspecified earlier version of > > UNIX. One of the changes was that "strcpyn" was renamed "strncpy". This > > predates V7, since it was called "strncpy" there as well. > > 0) As usual, Guy has pretty good model of the history, minor details: > > 1) index->strchr happened in UNIX/TS 1.0 (in some sense, System I of the System > V sequence). My 1.0 manual reads November 78; as I recall, this particular > change happened fairly early in the packaging effort that was trying to > get Edition 7 (late, but not released), PWB/UNIX 1.2, and some USG G3 > UNIX all back together. > > 2) strcpyn ->strncpy happened at the same time, early 78. The rename > was because some non-UNIX systems (GCOS, I think) took only the first > 6 characters, so that strcpy and strcpyn conflicted, a clearly bad thing. > > 3) In general, it is unwise to EVER label something as NIH unless you know > for a fact that it is NIH. There are more weird reasons for things being > different in different UNIX versions than you would ever believe; only a few > of them are NIH; it is always best to ask why things are different. > -- > -john mashey > UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash > DDD: 415-960-1200 > USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043 Mash: While we're arguing about who's the biggest pack rat, my PWB UNIX Usser's Manual Edition 1. It has neither strcatn nor strncat nor index in strings(III), but it does have an original "Programmer's Workbench Documentation Roadmap," Author J. R. Mashey, 01/18/77 :-) Joseph L. Wood, III AT&T Information Systems Laboratories, Holmdel (201) 834-3759 <ariel!>titania!jlw
guy@sun.uucp (Guy Harris) (08/02/85)
> Surprise, Guy, but 4.2BSD really CAN run many V6 binaries. ...However, this > is misleading. Certainly is. 4.2BSD can run PDP-11 V6 binaries (there are other V6 binaries), but V7 can't. ("stat" changed radically, and unlike the V7/4.2BSD change to "stat" it isn't source-compatible or binary-compatible. "seek" got replaced by "lseek".) 4.2 can do it because the compatibility-mode emulator simulates the system calls, and can simulate V6 calls as well as V7 ones. > not on a Sun or other 4.2BSD machine (where you won't find zork or chess.) For what it's worth, my Sun UNIX 2.0 manual has a section CHESS(6) - somebody here rewrote the assembler-language part of "chess" in 68000 assembler language. > Nonetheless, most V7 programs will compile and run happily on 4BSD, which > is not true of System V. Depends on how you define "most". V7 programs which assume "read"s and "write"s on slow devices return EINTR when a signal breaks through them don't run happily on 4.2BSD. S5 programs that don't use any library routines not in V7 (other than "strchr"/"strrchr") and don't do terminal "ioctl"s will (modulo a couple of exceptions, I suspect) compile and run happily on V7, 4.1BSD, 4.2BSD, ... (S5 programs that *do* use library routines not in V7 won't work, but then 4.2BSD programs which use library routines not in V7 won't work on V7 or S5 either.) Guy Harris
guy@sun.uucp (Guy Harris) (08/02/85)
> In article <133@maynard.UUCP> campbell@maynard.UUCP (Larry Campbell) writes: > >Hostile users aren't the only good reason to have quotas. What about > >buggy software that gets into an infinite loop writing to a file? > > That's what "ulimit" is for. Don't use an SST when roller skates will do. *ONLY* if the default "ulimit" is infinity, not the dumb 1MB that comes with S3/S5 out of the box from AT&T. Put a "ulimit" on programs you want to debug (note that an almost-identical facility, except for a signal SIGXFSZ which is delivered to the errant program, exists in 4.xBSD). DON'T penalize database systems which want to maintain big databases (and don't force me to run those systems as root just to boost their "ulimit"), or other programs which, for whatever reason, need files bigger than 1MB. Guy Harris
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/04/85)
> *ONLY* if the default "ulimit" is infinity, not the dumb 1MB that comes with > S3/S5 out of the box from AT&T. Yes, AT&T, please change this. A 1Mb default ulimit is unnecessary; the system manager could set this up in /etc/profile (like umask) if he thinks it is needed.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/04/85)
> The only thing terrible about ls -C is that it ought to be the default for > CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_ > brain damaged. I would sure get upset if when I ran "ls" in the long skinny window on my DMD, it didn't print the file names one per line. You are making the same mistake that a lot of the more crufty BSD software has made, namely: assuming an overly-restrictive model of how the software is to be used.
kk@cbrma.UUCP (08/04/85)
From: cbrma!kk > > If you're referring to the S3 terminal driver, from Bell's standpoint they > > didn't break anything. it's compatible with UNIX 2.0 (or PWB/UNIX 2.0 or > > whatever the hell the release before UNIX 3.0 was). The trouble is that the > > release that went out the door before System III was V7, not UNIX 2.0, which > > means the S3 driver's backward compatibility with UNIX 2.0 is totally > > useless to anybody outside the former Bell System. > And since most real UNICES are V7 derived, what does that say about Bell? Um, I'd like to bring this point in question for just a second. Although I work for Bell, I am neither (a) defending my company nor (b) trying to convince anybody that S3/S5 is better/worse than BSD/V7. I just want to question the statement that most UNICES are V7-derived. This is basically numbers-juggling, since the complaint is based on `most UNICES.' I work at Columbus Bell Labs. My department has something like 60 people in it. We have 2 VAX 780s, 2 PDP-11/70s, 1 3B, 7 PDP-11/73s, 6 PDP-11/23+'s, and 6-or-so PDP-11/23s. My understanding (more or less confirmed by my local sysadmin) is that my department is not particularly equipment-rich with respect to processors. All of our processors run USG Unix systems, i.e., S3 or S5. There are, in turn, around 550 people (last I heard) working here at Columbus BL. Scaling up my department's systems to account for the rest of the systems at this location means that there are in the vicinity of 200 processors running Unix systems around here. It is of course important that not all of them are running USG Unix systems; the obvious case in point is that Mark Horton works (lives?) somewhere on the next floor down, and his department works primarily with BSD, I guess; knock off a dozen processors for those VAXen and SUNs, and maybe another half dozen for some other department's systems that I don't know anything about. But I think the wide majority can be said to be running non-BSD stuff. My major point is this: Columbus is far from the largest of the Bell Labs locations; we're only a `branch' location anyway. There are something like 5000 people in the Indian Hill area, and I don't even want to guess who's in NJ. I'm aware of a sysadmin in Indian Hill who has responsibility for 28 VAXen on one floor alone. Try scaling those kinds of numbers up to account for who's running what version of the Unix system; I think it'll alarm you. Thus, I don't think it's reasonable or fair to say that most Unix systems are V7-derived. Just dealing with our own internal systems, it's nowhere near true, and I haven't even made the faintest attempt to consider outside customers who are buying S5 at a substantial pace. And, further, maintaining compatibility for all those folks who were doing things in UNIX 2.0 or PWB/UNIX x.x (long, long before I showed up here) was a substantial concern. Just a thought for reflection...someone will probably flame me anyway with `Yeah, but my company runs these <n> Widget-62s that are so popular and use BSD'...sigh. [This is probably completely unrelated to company position, of course.] -- Karl Kleinpaste
sambo@ukma.UUCP (Father of micro-S) (08/05/85)
In article <408@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >> The only thing terrible about ls -C is that it ought to be the default for >> CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_ >> brain damaged. > >I would sure get upset if when I ran "ls" in the long skinny window >on my DMD, it didn't print the file names one per line. So make ls check the width of the window, and do multi-column if possible according to the width of the window. ----------------------------------------- Samuel A. Figueroa, Dept. of CS, Univ. of KY, Lexington, KY 40506-0027 ARPA: ukma!sambo<@ANL-MCS>, or sambo%ukma.uucp@anl-mcs.arpa, or even anlams!ukma!sambo@ucbvax.arpa UUCP: {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!sambo, or cbosgd!ukma!sambo "Micro-S is great, if only people would start using it."
heiby@cuae2.UUCP (Ron Heiby) (08/05/85)
I guess that's what I deserve for following up to an article cross-posted with net.unix-wizards (trash dump). Really, I'm very sorry that I started a religious battle (or two or three) on V7 vs. 4BSD vs. SysV vs. ..... P-leeeeease read what I say and assume that I mean it if I don't use a smiley face. I made a remark about the different orientation of a research / teaching organization vs. a commercial computer vendor and suddenly I was accused of bad-mouthing products that had adapted software developed by the research / teaching organization. I made a remark that ulimit could be used in direct response to someone who asked about how to control / test "buggy software". I did NOT recommend that a small ulimit be used for database applications, nor did I recommend that it be a low value by default in all cases, nor did I suggest that it was a panacea that eliminated the need for other disk usage tracking and control tools. Good grief! Can we drop all this now and get on to something worthwhile? Or maybe we can at least leave the religious debates in net.unix-wizards and obviate the need for a mod.micro.att. -- Ron Heiby heiby@cuae2.UUCP (via ihnp4) AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
wcs@ho95e.UUCP (x0705) (08/05/85)
> > The only thing terrible about ls -C is that it ought to be the default for > > CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_ > > brain damaged. > > I would sure get upset if when I ran "ls" in the long skinny window > on my DMD, it didn't print the file names one per line. You are > making the same mistake that a lot of the more crufty BSD software > has made, namely: assuming an overly-restrictive model of how the > software is to be used. Actually, the SVR2 ls -C looks at the COLUMNS variable to find out how much space is available, and adjusts the number of columns accordingly. The 4.1BSD ls checked whether isatty(stdout), and set the output to single or multi-column accordingly; I always hated that since I normally wanted multi-column all the time. -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
peter@kitty.UUCP (Peter DaSilva) (08/05/85)
> > Most real world UNIX systems are STILL descendents of V7. > > Must be an alternate universe (see net.physics). Replace "real world" by "outside AT&T". WHat AT&T does internally on their 3B20Ds is pretty much irrelevent to what I want to do on my PDP-11. IBM is pretty braindamaged but even they don't require you to run MVS on your XT. AT&T was quite happy with having an external and an internal system before System III. Also most "non AT&T" UNIX systems predate System V. The ones that claim to be System III are almost all Microsoft or Unisoft releases and are V7 with SIII patches (which is why I didn't have to know about MIN & TIME when I was working on Xenix 3.0. Nice of Microsoft to tell me).
peter@kitty.UUCP (Peter DaSilva) (08/05/85)
> With respect to the discussion about the change from stty(2) to ioctl(2), > yes, stty is no longer included in official System V Release 2 documentation, > but it is still there in the kernal (it calls ioctl). If it's there it should be documented or porters will eat it. What are the parameters & structures this version accepts? V6 or V7?
peter@kitty.UUCP (Peter DaSilva) (08/06/85)
> > Surprise, Guy, but 4.2BSD really CAN run many V6 binaries. ...However, this > > is misleading. > > Certainly is. 4.2BSD can run PDP-11 V6 binaries (there are other V6 > binaries), but V7 can't. ("stat" changed radically, and unlike the > V7/4.2BSD change to "stat" it isn't source-compatible or binary-compatible. > "seek" got replaced by "lseek".) 4.2 can do it because the > compatibility-mode emulator simulates the system calls, and can simulate V6 > calls as well as V7 ones. Fine, as long as it doesn't use stat, sgtty, or lseek it's OK. How many programs use stat, sgtty, or lseek? Mainly system programs, which will come with the new system.
peter@kitty.UUCP (Peter DaSilva) (08/06/85)
> I would sure get upset if when I ran "ls" in the long skinny window > on my DMD, it didn't print the file names one per line. You are Then why don't YOU alias "ls | cat" and let the majority of the world work. It's these weird variants put in for esoteric special cases that really bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting stuff?
guy@sun.uucp (Guy Harris) (08/06/85)
> At Berkeley there were several V6 programs that there was no source to. They > were running on a 2BSD system (ucbcory). QED. That's nice. They sure as hell didn't use "seek" or "stat"... > > And there are programs written for V7 that will break when you try to > > compile them and run them under 4.2BSD... > > Actually once you change RAW to CBREAK they're quite compatible. I'll assume this statement refers to V6 vs. V7; I hope nobody is ignorant enough to think CBREAK was a Berkeley invention... > I've moved stuff between V5, V6, and V7 with few problems. Bet you had fun with the stuff using the old V5/V6 I/O library which was not available in V7... > SIII and SV are a royal pain, though. Only if you don't know what you're doing. I've moved stuff between V7 and S3/S5 with few problems. In case you're curious, I once (as a hack) got most of the way through turning V7 kernel source into S3 kernel source, working with on-line V7 source and an S3 kernel printout. I submit that the chances of a V6 binary running on S3/S5 are very close to the chances of a V6 binary running on V7 (PDP-11 binaries here - although, from a quick look at the system call and "exec" code of S5R2 and 4.2BSD, the chances look *very* good that you can run many S5 binaries under 4.2BSD!). At least V7's "lseek" and "stat" calls are the same in S5... (if I had a V6 manual, I'd check to see how compatible the V6 and V7 drivers' "sgtty" structures were, and then check how compatible the V6 and PWB/UNIX 2.0 structures - as used by S5 - were...) Then again, you can't run PDP-11 *or* VAX binaries on the 4.2BSD machine I'm typing this on, so the question of binaries is irrelevant anyway... Moving on to sources, I merely state again that I've moved code between V7, 4.2BSD, and S5 with few hard glitches. Converting "ioctl"s is certainly tedious, but *if* you know what you're doing there are few surprises. Of course, a number of flamers against the S3/S5 driver haven't bothered doing the work of figuring out the (admittedly complex) interface... (BTW, try porting an S5, S3 *or* V7 program which expects "read", "write", "wait", etc. system calls to be interrupted by signals to 4.2BSD. You may get a little surprise...) > > ...the S3 driver's backward compatibility with UNIX 2.0 is totally > > useless to anybody outside the former Bell System. > > And since most real world UNICES are V7 derived, what does that say about > Bell? It says that due to a mixture of technical and legal reasons they couldn't a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility or b) offer two versions of UNIX 3.0.1/S3. As for your claim that "most real world UNICES are V7 derived", I don't believe it. Period. Most commercial vendors are offering S3 or S5-based systems. Several 4.2 vendors are now offering 4.2BSDs that have some degree of S5 compatibility. Some of them are even clever enough to offer 4.2 functionality and S5 compatibility to the same programs as opposed to walling the two systems off in separate worlds. I suspect this will happen more in the future. I think enough has been said - more than enough, since most of the postings on this subject have been broadsides fired in religious wars rather than accurate discussions of the places where {V7,4.2BSD,S5} do well and where they do poorly. If anybody else wants to wage holy war over why their favorite version of UNIX is the "only true UNIX", could they please move the discussion to net.flame or net.religion.software? Guy Harris
jss@sjuvax.UUCP (J. Shapiro) (08/06/85)
> > The only thing terrible about ls -C is that it ought to be the default for > > CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_ > > brain damaged. > > I would sure get upset if when I ran "ls" in the long skinny window > on my DMD, it didn't print the file names one per line. You are > making the same mistake that a lot of the more crufty BSD software > has made, namely: assuming an overly-restrictive model of how the > software is to be used. I was waiting for someone to say that. I knew the net could be relied on for a straight line. Consider that generating multiple columns requires a know- ledge of terminal width, and that I did not insist that "ls" be stupid. I If my window is wide enough for two columns, that is how I want my display. There is a difference between being "crufty" and paying attention to detail and niceities that make life easier on a user. Whether -C should be the option or -1 should be the option should not be determined by your or my blathering. It should be determined by what the bulk of the users want, modified by what is feasible, reasonable, and sensible. Part of the pleasure of dealing with UNIX, to me, is the fact that utility programs don't insist on being unduly stupid. As to my model being overly restrictive, that is simply untrue, as I hope is now clear. Utilities ought to behave reasonably, and this in no way detracts from the robustness of my model - she's terrific;-) Jon Shapiro Haverford COllege
bruce@stride.UUCP (Bruce Robertson) (08/07/85)
In article <243@kitty.UUCP> peter@kitty.UUCP (Peter DaSilva) writes: >> With respect to the discussion about the change from stty(2) to ioctl(2), >> yes, stty is no longer included in official System V Release 2 >> documentation, but it is still there in the kernal (it calls ioctl). > >If it's there it should be documented or porters will eat it. What are the >parameters & structures this version accepts? V6 or V7? It is V6, unfortunately. I was very disappointed when I found this out, and promptly upgraded it to V7. -- Bruce Robertson UUCP: {ucbvax!menlo70,seismo}!unr70!unrvax!stride!bruce
guy@sun.uucp (Guy Harris) (08/08/85)
> ...the chances look *very* good that you can run many S5 binaries under > 4.2BSD!). Well, let me amend that to "S3 binaries"; S5 COFF binaries can't be executed by vanilla 4.2BSD, although the changes required are (relatively) localized (unless you want to execute demand-paged binaries from S5R2V2, in which case the fact that S5R2V2 is basically modeling a segmented/paged MMU on the VAX hardware, and as such wants to put segments on 64KB boundaries, will bite you - you can still do it, but it reaches the point of diminishing returns...) Guy Harris
mash@mips.UUCP (John Mashey) (08/08/85)
> > > ...the S3 driver's backward compatibility with UNIX 2.0 is totally > > > useless to anybody outside the former Bell System. > > > > And since most real world UNICES are V7 derived, what does that say about > > Bell? > > It says that due to a mixture of technical and legal reasons they couldn't > a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility > or b) offer two versions of UNIX 3.0.1/S3. I can't remember any legal reasons. The technical reason was real simple: remember that UNIX/TS -> PWB 2.0 -> SIII ->SV was a convergence process to desperately try to get a UNIX that more people could agree on and avoid having to make weird extensions; terminal driver was a notorious area for such extensions; too many people doing non-research projects found they needed other things. Again, ANYONE WHO EXPECTS TO GET UPWARD-COMPATIBLE RELEASES FROM SOMETHING LABELED RESEARCH does not understand research. Research versions of things and production, guaranteed-upward-compatible things are different animals [not better or worse, just different]. > > As for your claim that "most real world UNICES are V7 derived", I don't > believe it. Period. Most commercial vendors are offering S3 or S5-based > systems. Several 4.2 vendors are now offering 4.2BSDs that have some degree > of S5 compatibility. Some of them are even clever enough to offer 4.2 > functionality and S5 compatibility to the same programs as opposed to > walling the two systems off in separate worlds. I suspect this will happen > more in the future. I wish someone could quote numbers here; "most real world UNICES are V7 derived" is certainly true, since XENIX, V and 4.2 are all V7-derived. In the more specific sense of "V7, rather than III", this is probably true [numbers, somebody?] because I suspect there are a lot of V7-derived XENIX systems still out there [by sheer numbers of CPUs]. By number of users, who knows? > > I think enough has been said - more than enough, since most of the postings > on this subject have been broadsides fired in religious wars rather than > accurate discussions of the places where {V7,4.2BSD,S5} do well and where > they do poorly. If anybody else wants to wage holy war over why their > favorite version of UNIX is the "only true UNIX", could they please move the > discussion to net.flame or net.religion.software? Yes!! It is often more prudent to ask why a (dumb) decision was made than to flame upon its stupidity; sometimes environments and tradeoffs are different and you learn something. Some of the "X is better than Y" arguments are really "[in my situation] X is better than Y [and I don't have much experience with other kinds of situations] and therefore people who use Y must be communist mutants from space [or worse!] Here's a test case: how many people think UNIX is better than IBM's OS/MVS? .... If you answered: -What do you want to use it for? 10 points - good answer. -What's MVS? 5 points for honesty. -UNIX is better, of course - MVS is UGLYYYYY. - 0 points [because what you get to do is a 10 Gigabyte database with required response times that and needs a 3084.] Don't laugh; I've known people who tried to put projects like that on UNIX; not too many worked. Much insight can come from tradeoff analysis; sometimes by looking at differences we learn what the real general cases are and make progress by synthesizing better mechanisms that cover more cases; little progress is made in religious wars. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
guy@sun.uucp (Guy Harris) (08/08/85)
> IBM is pretty braindamaged but even they don't require you to run MVS on > your XT. That's a remarkably irrelevant example, considering 1) it has nothing to do with internal vs. external releases and 2) since MVS is written in 360 assembler and PL/S, and since the former *can't* run on an 8088 without a slow simulator and the latter probably has lots of 360-dependent goo in it, you couldn't run MVS on a PC anyway. > AT&T was quite happy with having an external and an internal system before > System III. I see no reason to assume they were happy about it. Remember a little something called the "Consent Decree"? AT&T *wasn't allowed* to be in the computer business *at all* before the breakup - there were suits from ADAPSO trying to get UNIX off the market! > Also most "non AT&T" UNIX systems predate System V. The ones that claim to > be System III are almost all Microsoft or Unisoft releases The HP ones? The CCI one? (more on that one later) The Plexus one? > and are V7 with SIII patches So what? The TTY driver seems to be your primary source of dyspepsia; I suspect most systems which are "V7 with S3 patches" have S3 libraries and a kernel which started out as a V7 kernel and got changed to resemble S3, including having the S3 tty driver dropped into it (I know that's how the CCI system was done, since I was one of the people who did it). As such, well, if it looks like a duck, and walks like a duck, and quacks like a duck, who cares if it's a goose with duck patches? > (which is why I didn't have to know about MIN & TIME when I was working > on Xenix 3.0. Nice of Microsoft to tell me). This has been explained to you elsewhere, but if you're clearing the ICANON bit, you either have to set MIN and TIME to get reliable results or they botched the tty driver. Guy Harris
mash@mips.UUCP (John Mashey) (08/08/85)
> Then why don't YOU alias "ls | cat" and let the majority of the world work. > It's these weird variants put in for esoteric special cases that really > bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting > stuff? "Weird variants put in for esoteric special cases..." is a pejorative description that could be read "I don't need this so it's dumb". A better way to have written this might be: "Does anyone know why SYS V accounting is included in the system? We haven't seen any use for it in our environment, and it seems particularly unnecessary for single-user workstations. Who uses it?" Now, the true facts [and I wrote it, so I know] are: a) It is (correctly) in the Optional part of the SYS V spec. b) Computer centers do like to be able to usage accounting so they can charge people money. This might not make sense if you've never used a computer center or run one, but it is true. c) Various people sometimes like to analyze system performance and usage [without actually charging people] by looking at the accounting output. V6 shell accounting was [in practice] found to be inadequate for real computer centers; there was a major push by BTL computer centers starting about 1977 to offer UNIX; we therefore tried hard to get a minimal mechanism to become part of V7 [many thanks to DMR for cooperation here] that would satisfy b) and c) above to avoid having every comp center do their own thing; the original version had to work on both V6 and V7's; had to work on PDP-11s; had to be a toolkit to adapt to different people's ideas of charging algorithms; ought to be reworked because requirements have changed! Weird? Esoteric? No, just different needs. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
peter@kitty.UUCP (Peter DaSilva) (08/08/85)
> course, a number of flamers against the S3/S5 driver haven't bothered doing > the work of figuring out the (admittedly complex) interface... First I had to FIND the interface. That's exactly my complaint. It's complex. It's also well hidden (what in the hell is it doing in the administrator's manual?????). > (BTW, try porting an S5, S3 *or* V7 program which expects "read", "write", > "wait", etc. system calls to be interrupted by signals to 4.2BSD. You may > get a little surprise...) This is a problem, though non-interrupting signals are nice they should have implemented it only in the new signal stack, leaving the old signals alone. 4.2 has 2 counts against it (signals and directories). SV has more than that. > > > ...the S3 driver's backward compatibility with UNIX 2.0 is totally > > > useless to anybody outside the former Bell System. > > > > And since most real world UNICES are V7 derived, what does that say about > > Bell? > > It says that due to a mixture of technical and legal reasons they couldn't > a) throw away the 2.0 compatibility in S3 replacing it with V7 compatibility > or b) offer two versions of UNIX 3.0.1/S3. Well, they should have made 2.0 compatible with V7 when it became obvious that V7 was succeeding outside Bell, but... c) keep the V6 system call emulation or change it to V7 emulation. Either would do. > As for your claim that "most real world UNICES are V7 derived", I don't > believe it. Period. Most real world UNICEs were installed before the SV interface definition came out. But examples: UniPlus+ SIII is actually V7 with some SIII additions. So is Xenix 3.0. The TRS80 Model 16 is an extremely common UNIX box. It's V7. > Most commercial vendors are offering S3 or S5-based > systems. Most SIII systems are actually V7 plus SCCS, as noted above. This is why I thought SIII was V7 compatible: all teh SIII systems I had used were actually V7. > they do poorly. If anybody else wants to wage holy war over why their > favorite version of UNIX is the "only true UNIX", could they please move the > discussion to net.flame or net.religion.software? You first.
peter@kitty.UUCP (Peter DaSilva) (08/08/85)
> >> With respect to the discussion about the change from stty(2) to ioctl(2), > >> yes, stty is no longer included in official System V Release 2 > >> documentation, but it is still there in the kernal (it calls ioctl). > > > >If it's there it should be documented or porters will eat it. What are the > >parameters & structures this version accepts? V6 or V7? > > It is V6, unfortunately. I was very disappointed when I found this out, and > promptly upgraded it to V7. Well if they'd document this & make sure it doesn't go away I'd drop any possible objection to the current ioctl. It's a lot more powerful, but for simple stuff (like setting rawmode) it's too complex.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/09/85)
> > > The only thing terrible about ls -C is that it ought to be the default for > > > CRTs. USG ls _requires_ the "-C" to get the multiple columns, which _is_ > > > brain damaged. > > > > I would sure get upset if when I ran "ls" in the long skinny window > > on my DMD, it didn't print the file names one per line. You are > > making the same mistake that a lot of the more crufty BSD software > > has made, namely: assuming an overly-restrictive model of how the > > software is to be used. > > Actually, the SVR2 ls -C looks at the COLUMNS variable to find out how much > space is available, and adjusts the number of columns accordingly. > The 4.1BSD ls checked whether isatty(stdout), and set the output to single or > multi-column accordingly; I always hated that since I normally wanted > multi-column all the time. Columnators should also do an ioctl(TIOCGWINSZ) or the DMD equivalent. Our "mpx" does not alter the COLUMNS environment variable for each layer, but rather stores the window size in the tty structure. Actually, if you want columnated "ls", given the way "ls" works it is necessary to either build the columnation into "ls" or to provide a very specific columnizing filter, since "ls" lists multiple directories WITH HEADERS so that simple-minded columnizing will mess up the output. I think the SVR2 method (requiring an explicit request for columnation) is preferable to Berkeley's automatic behavior. It is very easy to make up a shell function, alias, or script like l(){ ls -Cf $*; } to make your own personalized "l" command if you want one. Default command behavior should be simple, with complexities reserved for the options. P.S. I think I started the "ls" debate, but all I said was that I thought "ls -[a-z][A-Z]" was yucky (too many options to remember). I don't like a directory-entry listing utility having to know about terminal characteristics, though. This seems like an unnecessary combining of function. I like Peter Weinberger's idea of having a directory format that is directly printable: 10038 . 10039 .. 10502 myfile 10501 mydir etc. It would even be nice to get rid of . and .. I guess it's too late...
mark@cbosgd.UUCP (Mark Horton) (08/09/85)
In article <521@osu-eddie.UUCP> cbrma!kk@osu-eddie.UUCP writes: Sheesh! What does all this have to do with AT&T micros? Can't we move this discussion to, say, mod.unix? >the obvious case in point is that Mark Horton works (lives?) somewhere on the >next floor down, and his department works primarily with BSD, I guess; knock >off a dozen processors for those VAXen and SUNs, Lest anyone get the wrong impression, we have only 4 4.2BSD machines in our dept - one VAX, one Sun fileserver, and two Sun workstations. The rest of the machines mostly run System V (except for a Masscomp which is SIII derived, two SIII based HP machines, and a 6300 that runs Xenix.) Our project is committed to System V too. And strangely enough, I do go home a lot. Sometimes I get more work done from home than my office (and sometimes vice versa.) I can produce a lot nicer environment in my office at home than AT&T provides there. (Haven't figured out how to take my Sun workstation home yet, though.) >I just want to question the >statement that most UNICES are V7-derived. This is basically >numbers-juggling, since the complaint is based on `most UNICES.' Well, I could probably say just about anything here and produce a statistic to back it up. In terms of pure numbers, my understanding is that over half of the UNIX systems in the world today run Xenix. Since Xenix is V7 derived (with lots of System III and V stuff added in later) it can be reasonably said that ``most unices are V7-derived'' However, most Xenix machines are micros or even PC's, so this number can be misleading. Most of these machines don't connect into the net as we see it. (Whether such connection matters is no doubt part of your definition of "real world", which is certainly subject to some creative wording.) Another way of looking at it is this. Of about 2500 known machines on the UUCP network (not counting the various machines that we've just "heard of" but don't really know anything about), about half of them are owned by AT&T, and about half are in the outside world. And it's certainly true that most of AT&T has System V colored glasses on (internally it isn't even called System V, it's called "Standard UNIX", at least when spoken this is the term I usually hear.) There are a few pockets of 4.2BSD, but even these pockets tend to have lots of System V machines around too. So, assuming there are even a few System V machines outside AT&T, if you count the machines that are well enough known to be on UUCP, System V would win (and System V is NOT V7-derived.) Note that the typical 3B2 or UNIX PC or Xenix machine is NOT on the map, and believe me, there are gobs and gobs of them up and down the halls (not to mention the 6300's that people use as terminals.) Mark Horton
tim@cithep.UucP (Tim Smith ) (08/09/85)
>> I would sure get upset if when I ran "ls" in the long skinny window >> on my DMD, it didn't print the file names one per line. You are > >Then why don't YOU alias "ls | cat" and let the majority of the world work. Ever used a windowing system in a bit mapped display? HE will be part of the majority, not you. >It's these weird variants put in for esoteric special cases that really >bugs me about SV. How many AT&T 7300s are going to benefit from SV accounting >stuff? Excuse me, but it is not AT&T that is putting in special cases! And why is accounting a special case? You are perfectly free to turn off and remove all accounting stuff from your 7300 ( This is complete speculation on my part, but they couldn't have shpxrq(ROT 13) it up THAT badly, could they? ) -- Multi-column output should be handled in the terminal driver, so all program will be able to use it. :-) Tim Smith ihnp4!{wlbr!callan,cithep}!tim
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/11/85)
> > With respect to the discussion about the change from stty(2) to ioctl(2), > > yes, stty is no longer included in official System V Release 2 documentation, > > but it is still there in the kernal (it calls ioctl). > > If it's there it should be documented or porters will eat it. What are the > parameters & structures this version accepts? V6 or V7? Stty/gtty are there for binary compatibility, not for use in new code. Thus it doesn't matter if stty/gtty are removed during porting.
mark@cbosgd.UUCP (Mark Horton) (08/12/85)
In article <553@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >> Actually, the SVR2 ls -C looks at the COLUMNS variable to find out how much >> space is available, and adjusts the number of columns accordingly. > >Columnators should also do an ioctl(TIOCGWINSZ) or the DMD equivalent. >Our "mpx" does not alter the COLUMNS environment variable for each >layer, but rather stores the window size in the tty structure. It doesn't really look directly at COLUMNS. It calls setupterm and looks at columns, which setupterm sets. Setupterm (a standard low level terminfo routine) checks for COLUMNS, does the proper ioctls (JWINSIZE for the 5620, TIOGCSIZE for Sun, and presumably TIOCGWINSZ for the 7300, and then looks at the terminfo database. Given the lack of standardization of this important ioctl, software should not call this, but let setupterm do it for you. Termcap based systems should let tgetnum do the same thing, as happens on the Sun. >It is very easy to make up a shell function, alias, or script like > l(){ > ls -Cf $*; > } >to make your own personalized "l" command if you want one. > >Default command behavior should be simple, with complexities reserved >for the options. In fact, this is what I do. However, your last sentence is important. I agree with what it says, not with what you meant. "simple" may be different depending on whose viewpoint you take. From the implementers viewpoint, it's simpler to have it run down the left margin. From the novice user's viewpoint, it's simpler to have it appear in columns on the side of the screen than to (a) learn to lunge for ^S before it runs off the screen, (b) remember to type -C every time, or (c) learn how to make a .profile that contains the function. Mark
peter@baylor.UUCP (Peter da Silva) (08/13/85)
> > IBM is pretty braindamaged but even they don't require you to run MVS on > > your XT. > > That's a remarkably irrelevant example, considering 1) it has nothing to do > with internal vs. external releases and 2) since MVS is written in 360 > assembler and PL/S, and since the former *can't* run on an 8088 without a > slow simulator and the latter probably has lots of 360-dependent goo in it, > you couldn't run MVS on a PC anyway. OK. Take any IBM operating system and stick it in there. I'm not an expert on IBM. > > Also most "non AT&T" UNIX systems predate System V. The ones that claim to > > be System III are almost all Microsoft or Unisoft releases > > The HP ones? The CCI one? (more on that one later) The Plexus one? No, just most. A goodly percentage are TRS-80 model 16s. > > and are V7 with SIII patches > > So what? The TTY driver seems to be your primary source of dyspepsia; I > suspect most systems which are "V7 with S3 patches" have S3 libraries and a > kernel which started out as a V7 kernel and got changed to resemble S3, > including having the S3 tty driver dropped into it (I know that's how the > CCI system was done, since I was one of the people who did it). As such, > well, if it looks like a duck, and walks like a duck, and quacks like a > duck, who cares if it's a goose with duck patches? It doesn't quack like a duck since I took a program from V7 to Unisoft SIII and compiled it and it ran. No problems. > > (which is why I didn't have to know about MIN & TIME when I was working > > on Xenix 3.0. Nice of Microsoft to tell me). > > This has been explained to you elsewhere, but if you're clearing the ICANON Yes, it was explained by the OEM the "SIII" came from, after I asked him why the SIII wasn't SV compatible. > bit, you either have to set MIN and TIME to get reliable results or they > botched the tty driver. They didn't appear to have attempted to convert the TTY driver. VMIN and VTIME should never have been part of c_cc[] in the first place, so if they had converted it and made them seperate somewhere I'd hardly call it a botch. > Guy Harris Peter da Silva (wondering why he's still flaming me over VMIN and VTIME). PS: I don't know what current Xenix3 or Uniplus+ are like, so if they have "fixed" these "bugs" since the systems I was trying to port things between were released don't flame me for that. I get enough of it from Guy & Bill. -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
peter@baylor.UUCP (Peter da Silva) (08/13/85)
> Sheesh! What does all this have to do with AT&T micros? > Can't we move this discussion to, say, mod.unix? How about shutting it down? I've already admitted I blew it by claiming that SIII wasn't compatible with SV. I've explained why. The rest of the flames are matters of opinion & statistics. I don't even care if you have to type "lc" to get columns, for god sake, so long as I can get them, and I think cat -v is obscene! OK? Have I sufficiently placated the ghods? -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
peter@baylor.UUCP (Peter da Silva) (08/13/85)
> Ever used a windowing system in a bit mapped display? HE will be part of > the majority, not you. The majority will also have better things than ls for looking at directories. Like, say, icons? And have you ever done windowing at 300, 1200, or even 2400 baud? > Excuse me, but it is not AT&T that is putting in special cases! And why is > accounting a special case? You are perfectly free to turn off and remove all > accounting stuff from your 7300 ( This is complete speculation on my part, > but they couldn't have shpxrq(ROT 13) it up THAT badly, could they? ) It was my understanding from reading the manuals that it was implemented in the kernal, and thus couldn't be removed. I've been informed that this is not true. (wipes egg off face) -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
henry@utzoo.UUCP (Henry Spencer) (08/14/85)
> ... From the implementers > viewpoint, it's simpler to have it run down the left margin. From the > novice user's viewpoint, it's simpler to have it appear in columns on > the side of the screen than to (a) learn to lunge for ^S before it runs > off the screen, (b) remember to type -C every time, or (c) learn how to > make a .profile that contains the function. From *both* viewpoints, it is simpler to have pagination available in the tty driver. This means that the implementors don't have to kludge it into every program, and the users need neither lightning reflexes nor high sophistication. Try it, you'll like it. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
guy@sun.uucp (Guy Harris) (08/15/85)
> They didn't appear to have attempted to convert the TTY driver. VMIN and > VTIME should never have been part of c_cc[] in the first place, so if they > had converted it and made them seperate somewhere I'd hardly call it a > botch. If their system claims to be S3/S5 compatible, but doesn't permit you to set VMIN and VTIME and get the *documented* behavior, it's broken. Period. On the other hand, reading between the lines of what you're saying, it seems you were able to take a V7 program on some S3 port and compile and run it, *still using the V7 ioctls*. Fine. Lots of systems do that. However, this does not mean you "don't have to fiddle with MIN and TIME" or whatever you said. If you did TCGETA, turned off ICANON *but* didn't change MIN or TIME, and did TCSETA, either your program would get surprising results or it's running on a broken system. You didn't make it clear in your original comments that this is what you'd done. The fact that you tried doing the same "compile and go without changes" on somebody else's S5 system, where the UNIX/TS compatibility had *not* been replaced with V7 compatibility, says nothing about S3, S5, V7, or their relative compatibility. It says something about the vendors' documentation (they should have told people about the new tty driver) and about your willingness to read documentation (you yourself admitted that you hadn't *read* the documentation until recently). > Peter da Silva (wondering why he's still flaming me over VMIN and VTIME). Because it's *very* tiresome reading somebody making the same incorrect statement over and over again. It's unfortunate that the vendor's documentation, or somebody, didn't make the tty driver differences clear, and that it wasn't made clear that S3 and S5 don't normally have a V7-compatibility mode. However, the fact remains that 1) the drivers do require you to do things differently, in general, 2) some systems support V7 compatibility, but not all, and 3) just because a V7 program worked on an S3 system which was modified to support V7 ioctls does NOT mean that if the program doesn't work on an S5 system not so modified that a) S3 and S5 or incompatible, b) you don't have to worry about MIN and TIME if you use the S3/S5 ioctls or c) that the S5 which doesn't support the V7 ioctls is "broken". It's fairly clear that you don't have a thorough understanding of the differences between the TTY drivers. Could you please find a discussion where you have something to contribute other than content-free flames? Guy Harris
mark@cbosgd.UUCP (Mark Horton) (08/18/85)
In article <5877@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >From *both* viewpoints, it is simpler to have pagination available in the >tty driver. This means that the implementors don't have to kludge it into >every program, and the users need neither lightning reflexes nor high >sophistication. Try it, you'll like it. We have page mode in our tty driver too. I agree that it's a win to have page mode. However, in the specific case of the ls command, it's still much better to have it come out in columns. It's really useful to be able to see the entire directory at once, instead of having to look at it in snippets of 24 lines. Mark
peter@baylor.UUCP (Peter da Silva) (08/18/85)
> From *both* viewpoints, it is simpler to have pagination available in the > tty driver. This means that the implementors don't have to kludge it into > every program, and the users need neither lightning reflexes nor high > sophistication. Try it, you'll like it. You mean like on TOPS-20? Where it seems the tty drivers use TERMCAP or an equivalent (if you type more than 1 line & hit ^U it cursors to the beginning of the input line (maybe several terminal lines above) and sends a CL sequence! But back to the subject... I tried it. I didn't like it. It seems to be difficult to tell what's a page and what isn't. -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
peter@baylor.UUCP (Peter da Silva) (08/19/85)
> running on a broken system. You didn't make it clear in your original > comments that this is what you'd done. What I did (for the last time) is take the program, look up "ioctl" and "tty" in the appropriate sections of the manual, see that there were no changes or surprises, and compile. The manual did NOT contain any refs for termio in ioctl(2). Since the system is now SV, I can't check the SV code to see if it works on the putative SIII system. > The fact that you tried doing the same "compile and go without changes" on > somebody else's S5 system, where the UNIX/TS compatibility had *not* been > replaced with V7 compatibility, says nothing about S3, S5, V7, or their > relative compatibility. It says something about the vendors' documentation > (they should have told people about the new tty driver) and about your > willingness to read documentation (you yourself admitted that you hadn't > *read* the documentation until recently). I hadn't read the SYSTEM V docs until about a week after I started porting the program because I couldn't get them until them. That was several months ago, so if that's how you define recently, fine. I was never unwilling to read the docs, just unable to get them. The system I was working on and the docs were (and still are) over 30 miles away, at the house of a person with extremely exotic hours. > > Peter da Silva (wondering why he's still flaming me over VMIN and VTIME). > > Because it's *very* tiresome reading somebody making the same incorrect > statement over and over again. Who are you talking about? > It's unfortunate that the vendor's > documentation, or somebody, didn't make the tty driver differences clear, The standard Bell system V documentation didn't make it clear. Look at page 6 of the docs again. > and that it wasn't made clear that S3 and S5 don't normally have a > V7 compatibility mode. It wasn't made clear that SIII was anything but V7 with SCCS. In afct the system involved WASN'T anything but V7 with SCCS and a few other SIII utilities. SV is a different matter. I made the comment the SIII and SV were incompatible in one message. I apologised for the error and explained where and why I made the mistake. u!Some time AFTERWARDS you flamed me about it. Now I don't know whether that was network delay or you just not reading messages from me directed explicitly at you or what, but if it wasn't a case of network delay it was completely unjustified. > require you to do things differently, in general, 2) some systems support V7 > compatibility, but not all, and 3) just because a V7 program worked on an S3 > system which was modified to support V7 ioctls does NOT mean that if the You mean a V7 system modified to support the SIII utilities. > program doesn't work on an S5 system not so modified that a) S3 and S5 or > incompatible, b) you don't have to worry about MIN and TIME if you use the > S3/S5 ioctls or c) that the S5 which doesn't support the V7 ioctls is > "broken". I never said it was. I said that SV broke the SIII ioctls. As far as I was able to discern at the time it did. I'm not at a large corporation or Bell where I can get the documentation on every system I might happen to be working on (I'm an independant contractor, so I work on LOTS of machines) on short notice. I still have not got access to the SIII docs. NOT EVERYONE IN THE WORLD HAS ACCESS TO THE RESOURCES YOU DO! I made a mistake. I apologised for it. I explained why I made it. I still don't know why you found it necessary to badger me for it at a later date. > It's fairly clear that you don't have a thorough understanding of > the differences between the TTY drivers. How thorough do you want? I don't have a copy of the sources at hand, nor any of the ancilliary documents on the subject. I have the slightly obscure and ambigious documentation that Bell supplied, and using this I have managed to get several peices of screen-oriented software up on V7, 4.2, kinky SIII, kinky V7, and SV. It has been my experience that most implementations have differences in the drivers, but never had I run into as great a difference as that between SV and all the other systems I had used (with the exception of RSX :->). I have a problem remaining with a host-side XMODEM program that core dumps on SV. It's heavily patched code that includes stuff ported from MS-DOS and 4.2, as well as my own code. It has worked efficiently up to now. I don't know what on SV crashes it, and since the terminal driver is the biggest problem I have so far I immediately suspected it. I'm still not sure there's not a problem there... > Could you please find a discussion > where you have something to contribute other than content-free flames? > > Guy Harris Could you please discuss this without putting words into my mouth? Reply to net.flame. -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
john@frog.UUCP (John Woods) (08/20/85)
> From *both* viewpoints, it is simpler to have pagination available in the > tty driver. This means that the implementors don't have to kludge it into > every program, and the users need neither lightning reflexes nor high > sophistication. Try it, you'll like it. > I have tried it. I have yet to see a kernel based pagination scheme which I liked. I have seen a few that I liked less than typing ^S/^Q myself. The advantage of not having pagination in the kernel is the ability to have tailored paginators. Although, the TRIX operating system (done at MIT) would allow the kernel tty handler to call user code for pagination with as little (or as much) trouble as switching to any other kernel thread... Perhaps we are at the point where UNIX is retarding, rather than advancing, development of new ideas. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry > Oh, Henry, Henry, Henry. And I thought you had such good taste. Version 6 didn't have pagination, after all. ;-) -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA
gww@aphasia.UUCP (George Williams) (08/27/85)
> From *both* viewpoints, it is simpler to have pagination available in the > tty driver. This means that the implementors don't have to kludge it into > every program, and the users need neither lightning reflexes nor high > sophistication. Try it, you'll like it. > -- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry One problem with pagination in the tty driver: At caltech we have a network that lives between most computers and most terminals, now unfortunately the network uses ^S/^Q (of course) and any ^S, ^Q you type on your terminal will go to the network not to the computer. So putting pagination in the tty driver really confuses novice users, the documentation says that pressing ^Q gets things started again, but it doesn't. Instead they have to rummage arround, find the network documentation (which is not written for novices) find that what they really want is ^P^Q. I admit that I found this very useful when playing on a twenty many years ago, but when I started using our network I discovered that about half the lines I logged into had old processes hanging arround that just needed a ^P^Q typed on them. There must be a better soln. somewhere. George Williams cit-vax!aphasia!gww the moon is nothing But a circumambulating aphrodisia Divinely subsidized to provoke the world Into a rising birth-rate