dmr@research.UUCP (06/30/84)
Remarks are already rolling in on the LA Times article quoted by Will Martin; here's a reaction from one who observed the process. 1) It's a fact that fees for universities for all licenses through 32V (and thus through 4.2BSD) are negligible, and though lawyers and pedants may cringe at the phrase "give away thousands of copies ... to students" this was the effect. System III and V educational licenses are a lot more, but still, I think, pretty cheap. "Dozens" of universities understates; "hundreds" is more accurate. 2) There can be little quarrel with the assertion that this licensing policy was essential to the market success of Unix. 3) To suggest that the popularity of Unix (let's ignore the past year or so when national ads began to appear) owes to clever marketing is sheer lunacy. Imagine the fate of the hot young marketeer who advises "Well, let's test it for 8 years in the universities at below-cost prices. Think of the brand loyalty we'll build." The fact is that we had to fight every step of the way to get Unix out the door. The usual argument against each release was: if this stuff is really good, our competitors (yes, AT&T saw competitors even well before divestiture) will take it and use it against us! As it happened, the sensible people mostly won. However, any resemblance between the actual process and what is commonly thought of as marketing is distinctly coincidental. Dennis Ritchie
fair@dual.UUCP (Erik E. Fair) (07/06/84)
I'm waiting for the collective screams of those estimated 150,000
professionals and programmers when they realize that System V on
[insert random machine] isn't as good as 4.1/4.2 BSD on their alma
mater's vaxen...
``What do you mean, ^Z and ^W don't work here?
Why doesn't this UNIX act like the VAX at Podunk U?''
Wow! I coulda had a V8!
Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA
dual!fair@Berkeley.ARPA
{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
Dual Systems Corporation, Berkeley, Californiagwyn@brl-tgr.UUCP (07/06/84)
Thanks to all the Bell Labs folk who knew they had a good thing and were willing to fight to share it with us.
cmf@pegasus.UUCP (Chuck M. Fingerman) (07/10/84)
TO Erik E Fair, I have not personally used BSD unix so I can't make any speed claims, BUT how upward compatable is 4.1 to 4.2?? All AT&T BTL Unix's are upward compatable. Chuck Fingerman pegasus!cmf
jeff@gatech.UUCP (Jeff Lee) (07/11/84)
> TO Erik E Fair, > I have not personally used BSD unix so I can't make any speed claims, > BUT how upward compatable is 4.1 to 4.2?? > All AT&T BTL Unix's are upward compatable. > Chuck Fingerman > pegasus!cmf That's great. So is all Prime hardware and their operating system. So is all IBM hardware and then you can even run OS/360 to ensure the software compatibility. Upward compatibility in itself is not always good, but it is too often practical. To paraphrase the VMS jock who was slurring Unix(tm), you cannot change some of the bugs (bad defaults, bad design decisions) because too many programs depend on them. If total compatibility is your major concern, I don't think Unix(tm) is going to be the way to go. It is still too immature an operating system to depend on it being the same farther down the road. System V still lacks too many things that have to be re-invented everytime someone needs a certain service. A personal example is file locking. Other systems have supplied such things for 20 years. I still prefer the Unix(tm) environment to anything else on which I have worked, but I'm also willing to make the changes to things that happen to be incompatible. Other people are not and this causes them headaches. -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff.GATech @ CSNet-Relay uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff
guy@rlgvax.UUCP (Guy Harris) (07/12/84)
> TO Erik E Fair, > I have not personally used BSD unix so I can't make any speed claims, The file system is definitely faster. > BUT how upward compatable is 4.1 to 4.2?? 4.2BSD has a "compatibility mode" option where any VAX-11 binary built for 4.1BSD will execute under 4.2BSD, unless it tries to read directories (the directory format changed). > All AT&T BTL Unix's are upward compatable. If one takes that statement literally, so that "AT&T BTL UNIXes" isn't the same as "BTL UNIXes" (i.e., only referring to UNIXes offered *after* BTL changed it's name to AT&T BL), it's not a big statement; the only UNIX AT&T BTL ever offered was System V (can an S5R2 linker handle S5R1 object modules)? If one takes "AT&T BTL" to refer to Bell Labs generically, it's false as V6 wasn't upward compatible with V7, and (more importantly) V7 wasn't upward compatible with System III. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
guy@rlgvax.UUCP (Guy Harris) (07/12/84)
> TO Erik E Fair, > I have not personally used BSD unix so I can't make any speed claims, > BUT how upward compatable is 4.1 to 4.2?? > All AT&T BTL Unix's are upward compatable. I presume you're referring to the article which read > I'm waiting for the collective screams of those estimated 150,000 > professionals and programmers when they realize that System V on > [insert random machine] isn't as good as 4.1/4.2 BSD on their alma > mater's vaxen... > ``What do you mean, ^Z and ^W don't work here? > Why doesn't this UNIX act like the VAX at Podunk U?'' (although there was no "References:" line in your article, and you didn't bother including any relevant text from the article you were replying to - as was done above), but "isn't as good as" refers to several things here: 1) BSD UNIX supports the VAX-11 hardware far better than System V. For one thing, it correctly handles Translation Not Valid faults. The OS isn't supposed to panic when that happens, it's supposed to fetch the missing page from the disk. There are applications out there that *need* virtual memory (or, at least, run better with it than without it). 2) BSD UNIX supports most of the (conventional) devices that can be attached to a VAX-11, even those that the BTL UNIX developers don't like. Furthermore, it supports more {Uni|Mass}bus adaptor/device configurations than System III did (S3 was particularly dismal in this); S5 may actually realize that a user may want to have more than two MBAs and put some disks on one and some on another, or have two UBAs, or... but S3 sure didn't. 3) BSD UNIX's terminal driver has a superior user interface than do any of the BTL UNIXes (including V7) - the point made in the quote above. Why can't System V properly erase tab characters in ECHOE mode? Furthermore, the System V Release 2 "job control" mechanism is inadequate, because 1) there's no way to notify a program that does "funny things" to the terminal (screen editing, putting it in graphics mode, putting the keypad in application mode, etc.) that it's having control of the terminal taken away from it (so it can clear the screen, or put the terminal back in a "standard" mode that the program to whom the terminal is being given can use it) or that it's getting control of the terminal returned to it (so that it can redraw the screen or put the terminal back into the mode it was in when it left) and 2) there's no way to stop a job - all you can do is take the terminal away from it. It'd occasionally be useful to stop a job, examine it or correct an error, and restart it - which the BSD job control mechanism lets you do. 4) 4.2BSD UNIX supports networking sensibly. System V doesn't. And if the USDL people are as Berkeleyphobic as it has been claimed they are, System V isn't likely to in the near future. The Berkeley networking implementation *works*, and at least seems well designed for supporting multiple protocols (which is going to be a necessity for the forseeable future). 5) In some ways, 4.2BSD has better administrative facilities than System V. The auto-reboot stuff and "fsck -p" for preening file systems is nice, and the disk quota mechanism will come in very handy for some sites, to name two examples. I also think there are some things that System V does better. The System III/ System V "open" and "fcntl" calls are nice; so did Berkeley, as they adopted them for 4.2BSD. The shared memory is useful, although Berkeley plans to add it at some point. I personally prefer the System V "init" because it's more flexible than the old-style "init" (it's nice to be able to control arbitrary daemons from "init", and it's nice not to have to run "getty" as the login program on every terminal). The added functionality in the libraries and some of the commands are useful. "Terminfo" and Mark Horton's new "terminfo"-based "curses" are supposed to be superior to "termcap" and the earlier "curses". So how about declaring a truce, and both sides picking up the good ideas from each other? (Or developing a system which picks up the best of both worlds.) These sort of debates can be fun, just like the UNIX vs. VMS debates, but adopting the good ideas from other systems is generally more productive than playing NIH games and defending your favorite system when right and when wrong. (Are you listening, USDL?) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
jab@uokvax.UUCP (07/16/84)
#R:research:-103400:uokvax:6100037:000:944 uokvax!jab Jul 15 17:06:00 1984 /***** uokvax:net.unix / pegasus!cmf / 5:30 pm Jul 10, 1984 */ TO Erik E Fair, I have not personally used BSD unix so I can't make any speed claims, BUT how upward compatable is 4.1 to 4.2?? All AT&T BTL Unix's are upward compatable. Chuck Fingerman pegasus!cmf /* ---------- */ Oh, really? No, more accurately, "all versions of System V attempt to be upward-compatible." Ask a person who wrote a program using the "dbm" library from V7 how compatible V7 was with System V, where it isn't there. Ask a System III RJE user (who used the 2770 protocol to talk to an IBM, if he wanted) if System III is compatible with System V (which uses an incompatible protocol with no 2770 capibilities whatsoever). At this point in time, System V is trying to be compatible with new versions of System V. Period. Before submitting a cocky response like yours, check the facts and wording, before someone else does it for you. Jeff Bowles Lisle, IL
jpl@sftig.UUCP (07/16/84)
"Paging Mr. Harris, paging Mr. Harris, please come down to earth." Readers will recall from the last referenced article that one of Guy's major point's was that adopting other people's ideas is a useful and sensible thing to do. Quite so. However, this entails evaluating the ideas and the particular instantiation of those ideas, and not just swallowing them whole. Also, in future, when Mr. Harris plays the Great Reconciler, will he please refrain from baiting USDL (? Unix System Development Lab ?) members? They are certainly NOT -- what was the phrase? -- Berkeleyphobics. Au contrair, they generally seem capable of building on the best ideas for UNIX enhancements, whether originated at UCB or other universities, internal or external research labs, or even the occaisional original idea. jeff lankford sftig!jpl
henry@utzoo.UUCP (Henry Spencer) (07/17/84)
In response to (some of) Guy Harris's comments: > 1) BSD UNIX supports the VAX-11 hardware far better than System V. For > one thing, it correctly handles Translation Not Valid faults. The OS isn't > supposed to panic when that happens, it's supposed to fetch the missing > page from the disk. There are applications out there that *need* virtual > memory (or, at least, run better with it than without it). Although AT&T still has not gotten its finger out and added virtual memory to System V, other people have. The HCR people, in particular, gave a nice presentation about it at Usenix. They pointed out that virtual memory, done *right*, is nowhere near as complex as that awful mess inside 4.xBSD. > 2) BSD UNIX supports most of the (conventional) devices that can be attached > to a VAX-11, even those that the BTL UNIX developers don't like. Furthermore, > it supports more {Uni|Mass}bus adaptor/device configurations than System III > did (S3 was particularly dismal in this); S5 may actually realize that a > user may want to have more than two MBAs and put some disks on one and some > on another, or have two UBAs, or... but S3 sure didn't. Berkeley is still guilty of being parochial about device support, although I admit they aren't nearly as bad about it as AT&T. Even in 4.2, one can find drivers marked "never tested, beware", which probably means that they don't work. Claims to support device X should not be taken at face value. > 3) BSD UNIX's terminal driver has a superior user interface than do any > of the BTL UNIXes ... Oh really? I'm sure the people at Research snickered about this. Real windows are about 10000% better than Berkeley's awful "job control". (This is not to say that the folks at AT&T have done much better; neither 4.2 job control and V.2 layers is a real window system, even though that's what is *really* wanted.) > the System V Release 2 "job control" mechanism is inadequate, because 1) > there's no way to notify a program that does "funny things" to the terminal > (screen editing, putting it in graphics mode, putting the keypad in application > mode, etc.) that it's having control of the terminal taken away from it (so > it can clear the screen, or put the terminal back in a "standard" mode that > the program to whom the terminal is being given can use it) or that it's > getting control of the terminal returned to it (so that it can redraw the > screen or put the terminal back into the mode it was in when it left) ... Programs should not have to know these things, ever. The right way to do disciplined interaction with multiple processes (which is what it's all about, folks) is that the programs should never have to know *any* of this stuff, any more than an ordinary program has to know whether it's printfing to a pipe or a disk file. The multiplexing of user interaction should be a centralized function, not something that's distributed over every program that ever expects to participate in it! Yes, this means that screen redraw has to be centralized. This is the key item that AT&T missed. No credit to Berkeley, though, since they botched it much more badly. > there's no way to stop a job - all you can do is take the terminal away from > it. It'd occasionally be useful to stop a job, examine it or correct an error, > and restart it - which the BSD job control mechanism lets you do. Adding suspension and restart to a Unix kernel should be a one-hour hack, if you don't get it confused with multiplexing/windows/job-control/whatever. Doing it right would also fix some of the dreadful botches in the BSD stuff, like being able to suspend, say, passwd(1) in the middle of an /etc/passwd update. > 4) 4.2BSD UNIX supports networking sensibly. System V doesn't. ... "Supports networking", yes. "Sensibly", well... Many people have, uh, strong opinions on that subject. The lack of networking support in System V is definitely a defect, but emulating 4.2 is not necessarily the way to go. > So how about declaring a truce, and both sides picking up the good ideas from > each other? (Or developing a system which picks up the best of both worlds.) > These sort of debates can be fun, just like the UNIX vs. VMS debates, but > adopting the good ideas from other systems is generally more productive than > playing NIH games and defending your favorite system when right and when wrong. Dumping the *bad* ideas from each is at least as important as picking up the good ideas, and I see no sign that anyone is prepared to do that. The AT&T people seem bent on the "lots more features, union of all possible wishlists" approach to Unix development. And Berkeley's claim to fame seems to be based on quantity of new ideas rather than quality. "4.2BSD does everything UNIX does, only differently." I want V8. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (07/20/84)
"Clean up your act with Research Version 8" Unfortunately it does not appear that this system is going to be made generally available. How about everyone flooding the AT&T marketing types with demands for 8th Edition UNIX; maybe that would have some effect. Meanwhile, buy a bunch of Teletype 5620s and get the layers software running so you too can have real windows.
fair@dual.UUCP (Erik E. Fair) (07/20/84)
After being quoted so widely (and defended very well; Thanks Guy & friends), I feel somewhat obligated to respond. Guy Harris expanded on my terse jab eloquently, but the following pokes a *very* sore spot: >> From: jpl@sftig.UUCP >> Date: Mon, 16-Jul-84 06:35:45 PDT >> Organization: AT&T Bell Laboratories, Summit, NJ >> >> "Paging Mr. Harris, paging Mr. Harris, please come down to earth." >> >> Readers will recall from the last referenced article that one of >> Guy's major point's was that adopting other people's ideas is a >> useful and sensible thing to do. Quite so. However, this >> entails evaluating the ideas and the particular instantiation >> of those ideas, and not just swallowing them whole. >> >> Also, in future, when Mr. Harris plays the Great Reconciler, >> will he please refrain from baiting USDL (? Unix System Development Lab ?) >> members? They are certainly NOT -- what was the phrase? -- Berkeleyphobics. >> Au contrair, they generally seem capable of building on the best ideas >> for UNIX enhancements, whether originated at UCB or other universities, >> internal or external research labs, or even the occaisional original >> idea. >> >> jeff lankford sftig!jpl Mr. Lankford, I have seen more evidence of an epidemic class case of the famous ``Not-Invented-Here'' syndrome in the people who bring us System V than any other. I have never met anyone (at least not knowingly) who works for USG/USDL/(whatever-they're-calling-it-this-week) but I read their C code both in the Kernel and in the utilities. It is sloppy. It is in some cases unportable (a very important thing where I work; we do UNIX on a 68000, not a VAX or a 3B20). It does not often pass lint unscathed. But worst of all, it reflects a disturbing thing: that these people don't know how to complete something properly (e.g. the System III/V tty driver changes from V7: they changed the kernel, but they didn't do a complete conversion of the utilities, so they left a horrid compatability hack for stty(2) and gtty(2) in the kernel & C library, which didn't always work. Fercrissakes, ``getty'' still had stty/gtty calls in it!) I'm terribly afraid that AT&T is turning into IBM in the sense that they do backward compatability forever, and are terrified of fixing anything that is broken, just because it has always behaved that way. I cite the 4.2 BSD signal mechanism (although the implementation is messier) is the *right* way to do signals, and they should have been done that way in the first place. I very much doubt that USG/USDL will ever try to fix it. I echo the doubt of others that System V will ever do networking decently. Will they ever fix the filesystem? (and so on...) And if they're not Berkeleyphobic, then why don't System V VAXEN page? They've had three years to evaluate it... (flame off!) Erik E. Fair ucbvax!fair fair@ucb-arpa.ARPA dual!fair@BERKELEY.ARPA {ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair Dual Systems Corporation, Berkeley, California P.S. I wish I could see the look on their faces when IBM announces 4.2BSD for their entire line of computers...
seifert@ihuxl.UUCP (D.A. Seifert) (07/20/84)
> 3) BSD UNIX's terminal driver has a superior user interface than do any > of the BTL UNIXes (including V7) - the point made in the quote above. Why > can't System V properly erase tab characters in ECHOE mode? > > Guy Harris > {seismo,ihnp4,allegra}!rlgvax!guy It *can*. Ksh does. /bin/sh doesn't. -- _____ /_____\ "Get out there and keep moving forward!" /_______\ - Leo Franchi |___| Snoopy ____|___|_____ ihnp4!ihuxl!seifert
jpl@sftig.UUCP (07/20/84)
Although this may be just adding more tempest to the teapot, i feel obliged to respond to Eric'c article. I hope to avoid covering old ground. Why doesn't Brand X have option Y? This seems to have something to do with economics (I'll have to tread lightly here, as i'm no expert). The advantages and disadvantages of providing and supporting option Y are weighed in economic terms and a decision is then made (or should be). Additional factors come into play as well (should option Y' from brand Z be borrowed directly, should it be "improved", how long will it take, etc). These are all business decisions. The folks of CSRG at UCB don't do business, they do technical research. AT&T is in business for profit; hence, business decisions are therefore likely to be more marketing oriented, and probably somewhat less technically oriented. The distiction between business and technical decisions is not always as clear as i have implied (perhaps we are talking at cross-purposes?) Apologies to Guy; apparently it was someone else who was lost in space. jeff lankford sftig!jpl PS. As for inefficient code, well it appears about anywhere one may care to look, doesn't it? PPS. Perhaps we should move on to a less "religious" issue? Have we flogged this subject sufficiently?
guy@rlgvax.UUCP (Guy Harris) (07/21/84)
> > 3) BSD UNIX's terminal driver has a superior user interface than do any > > of the BTL UNIXes (including V7) - the point made in the quote above. Why > > can't System V properly erase tab characters in ECHOE mode? > > > It *can*. Ksh does. /bin/sh doesn't. OK, I rephrase my question: why can't System V's terminal driver properly erase tab characters in ECHOE mode? Ksh does, but that's because (I presume) it's not using the terminal driver, but doing its own erase/kill processing. "/bin/sh", and all other programs that let the terminal driver do erase/kill processing, don't because the terminal driver doesn't. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
ado@elsie.UUCP (07/21/84)
rlgvax!guy-- > ...Why can't System V properly erase tab characters in ECHOE mode? ihuxl!seifert-- > It *can*. Ksh does. /bin/sh doesn't. elsie!ado-- Okay. Now who at AT&T do I contact about getting Ksh for System V? -- UNIX is an AT&T Bell Laboratories trademark. -- ...decvax!allegra!umcp-cs!elsie!ado (301) 496-5688 (DEC, VAX and Elsie are Digital Equipment Corp. and Borden's trademarks)
clyde@ut-ngp.UUCP (Clyde W. Hoover) (07/23/84)
> Meanwhile, buy a bunch of Teletype 5620s and get the layers > software running so you too can have real windows. Great idea, Doug! Buy obsolete, clunky, overpriced pieces of junk to talk to a lobotomized version of UNIX. (Virtual memory? Networking? Virtual terminals? File locking? - Maybe In The Next Release [insert 3-5 year pause here]). "Clean up your act..." indeed! -- Clyde W. Hoover @ Univ. of Texas Computation Center; Austin, Texas (Shouter-To-Dead-Parrots) "The ennui is overpowering" - Marvin clyde@ut-ngp.{UUCP,ARPA} clyde@ut-sally.{UUCP,ARPA} ihnp4!ut-ngp!clyde
stevel@haddock.UUCP (07/25/84)
#R:research:-103400:haddock:16700031:000:751 haddock!stevel Jul 20 15:44:00 1984 >Also, in future, when Mr. Harris plays the Great Reconciler, >will he please refrain from baiting USDL (? Unix System Development Lab ?) >members? They are certainly NOT -- what was the phrase? -- Berkeleyphobics. >Au contrair, they generally seem capable of building on the best ideas >for UNIX enhancements, whether originated at UCB or other universities, >internal or external research labs, or even the occaisional original >idea. That explains system V.1 ar. And that wonderfull function left out of strip, adjusting archive symbol tables. Don't tell me they look carefully. Berkley got it right the first time, years ago. Currently suffering from Bell Brain Damage. Steve Ludlum, decvax!yale-co!ima!stevel, {amd70|ihnp4!cbosgd}!ima!stevel
ed@mtxinu.UUCP (07/26/84)
> ALL AT&T BTL Unix's are upward compatible.
????? How does one move a PWB (Unix 1.0) SCCS file to System V (5.0)?
The internal file formats changed somewhere along the way,
between 1.2 and 2.0, I think. What about object modules? Are
they compatible across versions (even staying within the same
hardware)?
If you're going to make generalizations like this when comparing
two systems, be sure they're right. Also, be sure that your
down-side statements ("BUT how upward compatible is 4.1 to 4.2??")
have some merit. Actually, there is quite a bit of compatability.
Most 4.1 sources will compile and run correctly on 4.2; virtually
ALL binaries (with two documented exceptions - reading directories
and the "jobs" library) can be run with "compatability mode"
compiled into the kernel.
Let's have serious technical comparisons of systems here, not
religious or marketing hype. There are features from both systems
(4.2 and SysV) that have merit, and features from both that
are disasters.
--
Ed Gould
{ucbvax,decvax}!mtxinu!edeugene@ames.UUCP (Eugene Miya) (08/02/84)
[][] AARGH! It happened again. I am trying to educate (inform) people about UNIX. 'Selling' U*X within an organization must be as difficult at retail sales. In trying to put together an informative document, I used the "six qualities" from the original UNIX paper by Ken and Dennis. You know: hierarchical file system, asynchronous processes..... I tried it on several interested people and I got questions back like: "What's an hierarchical file system? What good is that? Why not have it like xyz system?" "Why do I need asynchronous processes? Doesn't that waste cycles? [Or a similar line like: doesn't UNIX have batch? Doesn't interactive waste cycles?]" (Invariably these same people come back later saying "Is there same way, I don't have to wait for this thing to get done?....." .... It is easy to answer these questions face to face, or at least over a phone. The challenge is to do this on paper, in organizations that don't have access to systems already. You can certainly pose these questions in advance, but we come up with rationalizations for advantages..."The hierarchy allows you to group files into projects....You don't need to fill up you screen with an `ls`, and so on." One problem seems to be that many people in large organizations have vastly different ways of conceptualizing computing: IBMers say DATASETS others say "files." Another problem is the non interactive nature of written words. A third problem is that many companies offer their inhouse OS (e.g., RSX or VMS) which might compete with their own U*X ["These computer makers know their hardware, don't you think they would write the best OS for their machines?"]. Any ideas on educating the public in general writing? Lastly, I wish to say that in the FALL 83 COMPCON procs. a session was held comparing micro OSs. I think they looked at CP/M, MS/DOS, and UNIX. Clearly, the "cryptic" command naming took the greatest flack. We typically say, that the OS is not the command language or the name of the commands, IT is the "functionality." This is obviously got to change because it represents the one greatest weakness to 'sellng' U*X. --eugene miya NASA Ames Res. Ctr.
gsp@ulysses.UUCP (Gary Perlman) (08/03/84)
Paper. Sigh. Paper was invented before interactive systems were developed. Paper was invented before graphics sstems were developed. And so on. I have found paper to be an impovershed medium for explaining systems. I suggest you try video. Nothing fancy. Just get a VCR and a camera and stick it in front of your terminal and go. Talk about the file system and do a few cd's and ls's. Show how to put a process in the background and show how you can go on to other tasks. I can't overstate the difference between seeing a demo and reading about capabilities. There is no comparison. If you do not have a video system, they are not too expensive. The cheapest recorder with 0 options, a B&W monitor, and an outdated camera will probably do fine. I am sorry to have to say that $1500 is the least you can get away with--this make video out of the range of many sites--but somethng expensive that works is better than something cheap that does not.
ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (08/04/84)
.
.
.
That explains system V.1 ar. And that wonderfull function left out
of strip, adjusting archive symbol tables. Don't tell me they
look carefully. Berkley got it right the first time, years ago.
Currently suffering from Bell Brain Damage.
Steve Ludlum, decvax!yale-co!ima!stevel, {amd70|ihnp4!cbosgd}!ima!stevel
They got it right years ago, eh? How about that brain-damaged
Berkeley TTY driver--when will they get it right? (BTL's is much
better...) They've both got warts, and both have different
applications.
Dave Ihnat
ihuxx!ignatzguy@rlgvax.UUCP (Guy Harris) (08/07/84)
> They got it right years ago, eh? How about that brain-damaged > Berkeley TTY driver--when will they get it right? (BTL's is much > better...) They've both got warts, and both have different > applications. Well, I think the USG tty driver has a better "ioctl" interface (although some may disagree), but the Berkeley one has a better user interface (i.e., it actually knows how to implement "crt rubout"). The Berkeley one gets a lot of its cruftiness from a BTL tty driver, namely the V7 driver, which was a bag on the side of the V6 driver. The Berkeley driver was a bag on the side of the V7 driver, but this was done for backward compatibility (as was the V7 driver, probably). Some people have complained about "gratuitous incompatibilities" introduced by the USG driver (although I have seen a mail message from one of those people referring to the USG driver's "much cleaner than v7" tty driver interface). Some of the problems might be cleared up by getting rid of the UNIX 2.0 backward compatibility stuff in the USG driver, and putting in V7 backward compatibility stuff instead (within AT&T, V7 backward compatibility was probably less useful than UNIX 2.0 backward compatibility; outside AT&T, nobody had UNIX 2.0 so V7 compatibility is more useful). We put that into our System III system, and it was reasonably happy running a version of Rogue and a version of "mille" built for a system with a V7 driver. (The 4.1c driver made an attempt at cleaning up the interface somewhat, by adding "ioctl"s to get/set all 32 mode bits, and to get/set all the control characters; this was backed out of 4.2. The USG driver's interface may have been considered at some point for the Berkeley driver, but rejected for reasons of backward compatibility.) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
mwm@ea.UUCP (08/10/84)
#R:research:-103400:ea:13400013:000:669 ea!mwm Aug 10 11:15:00 1984 /***** ea:net.unix / sri-arpa!ARPA / 4:14 pm Aug 6, 1984 */ From: "Scott M. Hinnrichs" <SMH@SRI-KL.ARPA> Trying to convince the uninitiated how useful and wonderful UNIX is is really like convincing someone how wonderful it is to use a screen editor or spreadsheet for the first time; once they have used it they find they cannot live without it and wonder how they ever got along without it! Scott /* ---------- */ And of course, after they've learned it, trying to convince them that something else might possibly be better than Unix for their application is harder than getting them to use it in the first place. So much for learning to be flexible. <mike