Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site frog.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!genrad!panda!talcott!harvard!think!mit-eddie!cybvax0!frog!john From: john@frog.UUCP (John Woods) Newsgroups: net.micro.att,net.unix-wizards Subject: Re: Re: instability in Berkeley versus AT&T releases (absurdly long) Message-ID: <276@frog.UUCP> Date: Tue, 20-Aug-85 14:00:38 EDT Article-I.D.: frog.276 Posted: Tue Aug 20 14:00:38 1985 Date-Received: Sun, 25-Aug-85 04:23:15 EDT References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp>, <1392@cbosgd.UUCP> <5877@utzoo.UUCP> Organization: Charles River Data Systems, Framingham MA Lines: 25 Xref: watmath net.micro.att:481 net.unix-wizards:14514 > 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