geoff@desint.UUCP (Geoff Kuenning) (08/04/85)
In article <311@baylor.UUCP> peter@baylor.UUCP (Peter da Silva) writes: >There's no commercial reason for changing the name of Mail to mailx, or >TURNING OFF the use of '.' as well as '~.' to terminate a message, or >rehacking the terminal driver so V7 >programs no longer work, and so on. (1) Differentiating programs (or variable names) by capitalizing the word (and not even the *whole* word!) is at best bad human engineering, and at worst sheer idiocy. Is it any wonder Bell chose to do it a bit better, especially now that experience has had a chance to prove Berkeley's decision wrong? (2) Count on Berkeley to provide two ways of doing things when one would do. '~.' is a standard exit for a lot of programs (e.g., cu, tip), as is '.'. Providing options confuses people without adding significant functionality. (3) The USG TTY driver is a clean, orthogonal design that is easy to get to do what you want. You've never seen a posting of "how do I get an 8-bit data path with ^S/^Q flow control" (needed for many laser printers) for USG because it's so easy. Sometimes you have to bite the bullet for the future. > Like it or no, at the time Bell came >out with System III, THE standard system in the real world was V7. THE standard system in the educational world was V7. The standard system in the rest of the world was RSX, or TOPS-20, or OS/370. >There >is no good excuse for making SIII incompatible with V7. Untrue. There are frequently excellent COMMERCIAL reasons to drop compatibility or at least reduce it in the interests of making use of what one has learned. (PDP-8? What's that?) >Or for >making SV incompatible with SIII. They didn't. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff
peter@kitty.UUCP (Peter DaSilva) (08/08/85)
> especially now that experience has had a chance to prove Berkeley's decision > wrong? It has? News to me. The current usage seems to be: BSD USG mail mailx binmail mail And what's so terrible about "nmail", whuch has the advantage of being reasonable mnemonic for New MAIL? > (2) Count on Berkeley to provide two ways of doing things when one would do. > '~.' is a standard exit for a lot of programs (e.g., cu, tip), as is '.'. > Providing options confuses people without adding significant functionality. But '.' is the standard exit for old mail. I'm using connect (variant of cu) to call this system. I've hung up a couple of times by forgetting to type "~~.". Why not keep the compatibility eith your own software? > (3) The USG TTY driver is a clean, orthogonal design that is easy to get to > do what you want. You've never seen a posting of "how do I get an 8-bit > data path with ^S/^Q flow control" (needed for many laser printers) for USG > because it's so easy. Sometimes you have to bite the bullet for the future. Now that I've found the well-hidden documentation on the USG driver I have to agree it's orthogonal. Overloading EOF and QUIT as MIN and TIME was a bad mistake, since it makes the intuitive transform between V7 and relatives and SIII and relatives a total loss... and adds extra stuff you have to save and restore when changing modes. > > Like it or no, at the time Bell came > >out with System III, THE standard system in the real world was V7. > > THE standard system in the educational world was V7. The standard system > in the rest of the world was RSX, or TOPS-20, or OS/370. The standard UNIX system. Ever hear of Microsoft? Or Venturcom? Or Unisoft? That's a straw man & a very bad argument. > >There > >is no good excuse for making SIII incompatible with V7. > > Untrue. There are frequently excellent COMMERCIAL reasons to drop > compatibility or at least reduce it in the interests of making use of what > one has learned. (PDP-8? What's that?) But is this the case here? You say yes. I say no. Microsoft's Xenix 3.0 is compatible with V7 and looks like SIII. It's the most common UNIX system on small machines. > >Or for > >making SV incompatible with SIII. > > They didn't. You're right. I was using a Unisoft SIII and Xenix 3.0 when I said this. Both were V7 with some cosmetic changes. I apologise for this misconception, however understandable. > -- > Geoff Kuenning
guy@sun.uucp (Guy Harris) (08/12/85)
> It has? News to me. The current usage seems to be: > > BSD USG > > mail mailx > binmail mail > > And what's so terrible about "nmail", whuch has the advantage of being > reasonable mnemonic for New MAIL? I agree "mailx" is kind of a gross name. However, a quick look at the 4.2BSD distribution indicates there is *no* such program as "binmail". There is "/bin/mail", which is the old "mail", and "/usr/ucb/mail" and "/usr/ucb/Mail", which are two links to the new "mail". You can get the new "mail" by putting "/usr/ucb" first in your path (which is OK) or by typing "Mail" (which is kind of gross). > Overloading EOF and QUIT as MIN and TIME was a bad mistake, since it makes > the intuitive transform between V7 and relatives and SIII and relatives a > total loss... and adds extra stuff you have to save and restore when > changing modes. Agreed (there are proposals presented by AT&T people to the /usr/group standards committee to fix this, so even they realize it was a botch). I usually save and restore *everything* when changing modes, so that part isn't a problem, however. > You're right. I was using a Unisoft SIII and Xenix 3.0 when I said this. > Both were V7 with some cosmetic changes. Considering how similar the V7 and S3 kernels (PDP-11 kernels, anyway) were, modulo the TTY driver, that part of the V7 vs. S3 debate is somewhat irrelevant. CCI and, I believe, Microsoft set up their "V7 kernel made into an S3 kernel" with an S3 TTY driver with a "compatibility aide" (*sic* - that's how it's spelled in the comment, but considering how many kern*e*l hackers spell it "kernal" I shouldn't be too upset) for V7 rather than UNIX/TS 1.0 and PWB/UNIX 2.0. Guy Harris
friesen@psivax.UUCP (Stanley Friesen) (08/14/85)
In article <277@kitty.UUCP> peter@kitty.UUCP (Peter DaSilva) writes: > >> (3) The USG TTY driver is a clean, orthogonal design that is easy to get to >> do what you want. You've never seen a posting of "how do I get an 8-bit >> data path with ^S/^Q flow control" (needed for many laser printers) for USG >> because it's so easy. Sometimes you have to bite the bullet for the future. > >Now that I've found the well-hidden documentation on the USG driver I have to >agree it's orthogonal. Overloading EOF and QUIT as MIN and TIME was a bad >mistake, since it makes the intuitive transform between V7 and relatives and >SIII and relatives a total loss... and adds extra stuff you have to save >and restore when changing modes. > Is this why the default values for MIN and TIME are not a sane 1 and 0 like they should be!?!? Really, while orthoganality and flexibility are fine goals, so is *simplicity* of *use*. From what I have seen the Sys3/5 ioctl system is a real pain to use correctly. In breking out the various operations the designers seem to have forgotten the principle of leaving the most common operations *simple*, that is such frequent transitions as turning CR mode on or off, or going to single character input should be *atomic* operations. The only really simple improvement was the OPOST idea, which Berkeley has implimented as LLITOUT! Maybe I should get the ioctl system I designed few years ago and post an outline of it to the net!(It is of course unimplemented). Gee, what a choice, the inflxibility of V7 ioctl or the overweaning complexity of Sys3/5 ioctl! Someone *please* implement a rational system. -- Sarima (Stanley Friesen) {trwrb|allegra|cbosgd|hplabs|ihnp4|aero!uscvax!akgua}!sdcrdcf!psivax!friesen or {ttdica|quad1|bellcore|scgvaxd}!psivax!friesen
john@basser.oz (John Mackin) (08/17/85)
In article <651@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > Gee, what a choice, the inflxibility of V7 ioctl or the > overweaning complexity of Sys3/5 ioctl! Someone *please* implement > a rational system. They have, it's called a "stream". See the October 1984 BSTJ.
hammond@petrus.UUCP (Rich A. Hammond) (08/19/85)
> Stanley Friesen writes in reference to ioctl (Sys V vs BSD): > ... The > only really simple improvement was the OPOST idea, which Berkeley has > implimented as LLITOUT! Maybe I should get the ioctl system I designed > few years ago and post an outline of it to the net!(It is of course > unimplemented). > Gee, what a choice, the inflxibility of V7 ioctl or the > overweaning complexity of Sys3/5 ioctl! Someone *please* implement > a rational system. > Well, at least on my BSD system LLITOUT doesn't work properly, it takes more than one ioctl to get its effects propagated through the driver. On the other hand, the last Sys V I used, OPOST worked fine, and with KMC's the output speed was pretty nice. Besides, the man pages for my 4.2 BSD tty(4) are 9.5, for Sys V termio(7) they are only 7. I don't find Sys V more complex, but tastes differ. Rich Hammond