john@basser.oz (John Mackin) (04/04/86)
In article <127@sering.mcvax.UUCP> dpk@sering.UUCP (Doug Kingston) writes: > I use BLIT terminals and SUN-like > workstations every day. However, this does not mean I want to give > up the ability to STOP and RESTART jobs. [...] > In order to get a consistent coredump > you must insure the process is NOT running. Job control allows you > to accomplish just that. It is then possible to safely collect the > processes context from /dev/*mem (using the "gcore" program in 4.2BSD). > You can then continue the process afterwards with no ill effects. > [...] > In summary, look at the broader uses of BSD job control before condemning > its usefulness. Its not just for allowing simultaneous processing. [...] > I believe that the BSD facilities and many more are > provided through /dev/proc on V8 Unix, although they may not be as efficient. Well. First of all let's split some hairs. [Please note that I'm not attacking you or your posting, but I do value correctness... ok, I'm pedantic.] I do not think you use Blit terminals (note correct capitalization) every day. I am quite certain that what you mean is that you use Teletype DMD5620 terminals every day. A Blit is a research terminal, manufactured first at Bell Research and then by Teletype exclusively for Bell Research. No Blits have ever been sold commercially. They have a 68000 cpu and 256K of ram which cannot be expanded. Blits have a VT-100 style keyboard; the key layout is precisely the same as a VT-100. The Teletype DMD5620 is a commercial product. It has a WE32000 cpu and 256K of ram which can be expanded to 1M. It has a completely different keyboard, with white, low-profile keys. I emphasize this because I am typing this on a Blit. We have an Eighth Edition license and Bell Research have donated 12 Blits to us. The Teletype DMD5620 can be unambiguously referred to as: a 5620 (probably best), a dmd (popular with SysV'ers) and a dud (but not many people outside the Labs call them that). The term "jerq" should be avoided as it can refer to either a Blit or a dud depending on context (to a person at the Labs, it means a Blit; to a person at a non-Labs V8 site, it probably means a dud). Also on terminology, you refer to /dev/proc. The conventional mount point of the Eighth Edition process file system is /proc. I do not believe anyone ever mounts it on /dev/proc. Now that I've got that out of the way, let's go on to discuss so-called job control. The whole point about Berkeley job control is, it is a massive hack. Witness the huge number of user-mode programs that had to be modified to know about SIGTSTP, etc. Not to mention the far-reaching kernel modifications. I think we can agree that a window system *in which the user program need have no idea that it is running in a window* is much better. You say as much, but then you say you still want to be able to stop and restart processes. On V8, that is as easy as opening the process' /proc entry and doing a single ioctl(). No harder than doing a kill(). For the purposes you say you use the facility, having it generated from a character typed on the controlling terminal (^Z) is pretty pointless. So there's no clear advantage there. I'm not sure what you mean by saying that the V8 ways of doing things ``may not be as efficient''. I think it's pretty clear that the number of milliseconds it takes to stop a process doesn't matter at all, given the very low frequency with which it is done; and in any case, it's not clear that V8 will do this any less efficiently than other systems. And if you mean efficient in terms of efficient for the user -- believe me, V8 is by far the best UNIX environment I've ever used (I've used quite a few). The software you get for 5620's with the SysV layers package, or with BSD, is nowhere near as nice as that under V8. Please don't judge Eighth Edition on the basis of inferior imitations. As far as stopping, making a core, and restarting goes, or in general for debugging anything, may I recommend the V8 debugger, ``pi''. I could easily use too many superlatives talking about pi. Let me just say that it is a lot more satisfying to be able to dynamically bind the debugger to any process in the system, *while it is executing*, and set breakpoints, examine its stack, ... than to take a core dump and prod that. (Of course you can simply stop the process, too.) Think of it this way: there's a certain beauty in surgery, but autopsies just stink. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia seismo!munnari!basser.oz!john john%basser.oz@SEISMO.CSS.GOV
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/04/86)
In article <559@basser.oz> john@basser.oz (John Mackin) writes: >In article <127@sering.mcvax.UUCP> dpk@sering.UUCP (Doug Kingston) writes: >> [omitted] >A Blit is a research terminal, manufactured first at Bell Research >and then by Teletype exclusively for Bell Research. I thought a little company in NY (whose name I forget) had the contract? Another significant difference between the Blit and the 5620 would seem to be the color of the display; didn't the Blit have a white phosphor? The word size difference shows up in the existence of both texture and texture16, yuck. >Also on terminology, you refer to /dev/proc. The conventional >mount point of the Eighth Edition process file system is /proc. >I do not believe anyone ever mounts it on /dev/proc. That's probably my fault; I have referred to this as /dev/proc a few times. It seemed to me that calling it /proc wouldn't convey the special nature of the /proc filesystem type. >You say as much, but then you say you still want to be able to >stop and restart processes. On V8, that is as easy as opening >the process' /proc entry and doing a single ioctl(). No harder >than doing a kill(). For the purposes you say you use the >facility, having it generated from a character typed on the >controlling terminal (^Z) is pretty pointless. So there's >no clear advantage there. ?? How do you get the /proc entry open etc. in the first place, except from a Blit-like terminal where you already have multiple processes? It seems to me you need to press some key on a normal terminal. >As far as stopping, making a core, and restarting goes, or in >general for debugging anything, may I recommend the V8 debugger, >``pi''. Yes, yes! When will this be generally available?
chris@columbia.UUCP (Chris Maio) (04/05/86)
In article <559@basser.oz> john@basser.oz (John Mackin) writes: >Now that I've got that out of the way, let's go on to discuss >so-called job control. The whole point about Berkeley job control >is, it is a massive hack. Witness the huge number of user-mode >programs that had to be modified to know about SIGTSTP, etc. >Not to mention the far-reaching kernel modifications. I think >we can agree that a window system *in which the user program >need have no idea that it is running in a window* is much better. > >You say as much, but then you say you still want to be able to >stop and restart processes. On V8, that is as easy as opening >the process' /proc entry and doing a single ioctl(). No harder >than doing a kill(). For the purposes you say you use the >facility, having it generated from a character typed on the >controlling terminal (^Z) is pretty pointless. So there's >no clear advantage there. Without a window system or a second terminal, how do you suspend foreground processes? How much extra work is involved in suspending an entire process group? And if there's no point in having a special character to suspend a process, why have one to kill a process? (Or to generate a core dump? Now *that* is strange.) In the TOPS-20 operating system, there is a special character to suspend a process group, but none to kill a process group -- TOPS-20 gives you roughly the same process manipulation capability as Berkeley job control with only a single interrupt character. Imagine that. The "huge number of programs that have to be modified to recognize SIGTSTP" is a poor argument, in my opinion. Sure, the shells and stty have to know about it, but (and correct me if I'm wrong) any other program modified to know about it has only been modified to make it more user-friendly (e.g. redrawing a curses screen), not because it was absolutely necessary. And surely this is no less work than modifying the same programs to know about window resizing under a window system (ideally they shouldn't have to, but you know that they will). There are other arguments that have been stated before. The bottom line for me is that regular users appreciate berkeley-style job control semantics and are loathe to give them up once they've used them, and windowing displays are always going to be more expensive than "dumb" terminals. Providing a flexible process control mechanism for the ordinary user seems to me a lot more important than providing fancy window systems; what do window systems have to do with UNIX anyway?
dpk@mcvax.uucp (Doug Kingston) (04/05/86)
John Mackin: I am very aware of the facilities in V8 and that it is a superior system to other UNIXes in most (all?) respects. However, it is totally unaccessable to my organization and 99.9 percent of the rest of the UNIX community. I like 'pi' too. We all enjoy and appreciate hearing about the new and interesting features or approaches taken in V8 or other UNIXes, but try to avoid "bragging". It just makes us angry. Give me /proc and I'll pitch BSD job control. Deal? Cheers, -Doug-
guy@sun.uucp (Guy Harris) (04/07/86)
> Now that I've got that out of the way, let's go on to discuss > so-called job control. The whole point about Berkeley job control > is, it is a massive hack. Witness the huge number of user-mode > programs that had to be modified to know about SIGTSTP, etc. > Not to mention the far-reaching kernel modifications. I think > we can agree that a window system *in which the user program > need have no idea that it is running in a window* is much better. Yes, a number of programs did have to be modified. Most didn't. Roughly 7% were modified. If you then drop in, say, a bunch of S5 (or V8, or whatever) programs, most of them need no modification. The programs that were modified were modified because: 1) they need to undo what they've done to the terminal if they get stopped (note that this doesn't just mean "clear the screen") and redo it when they're restarted (note that this doesn't just mean "redraw the screen") - this covers about 7 programs 2) they need to prevent themselves from being stopped while in a critical region - this covers about 4 programs 3) they need to be able to report what the signal that stopped a child process was - this covers about 2 programs 4) they need to set up the initial signal environment for a login session - this covers about 3 programs 5) they need to be able to control jobs - this covers 1 program ("halt" and "reboot" use it because they have to tell "init" something and "init" uses SIGTSTP for this; "init" uses it because it's there, not because it has any real significance.) Yes, it's a nuisance, but I don't think it justifies uncritical claims about how awful job control is because of "a huge number" of programs requiring modification because of it. Yes, I agree that a window system (which job control is NOT) which permits programs to run without having to know that they're in a window is better than one which doesn't. I rarely use job control here, because I have such a window system. However, bit-mapped terminals and workstations are expensive, and saying that thus-and-such a problem is solved completely and correctly by such machines is all well and good, but it doesn't mean that this solves everybody's problem or that no other solutions should be considered. (To give another example, it has been argued that terminals like Blits render the ^R control character and the "printing terminal erase" mode of 4.2BSD unnecessary. What they really mean is that such features are unnecessary *if you have something like a Blit*. Since not everybody does, such features are still useful.) > As far as stopping, making a core, and restarting goes, or in > general for debugging anything, may I recommend the V8 debugger, > ``pi''. I could easily use too many superlatives talking about > pi. Let me just say that it is a lot more satisfying to be > able to dynamically bind the debugger to any process in the > system, *while it is executing*, and set breakpoints, examine > its stack, ... than to take a core dump and prod that. (Of > course you can simply stop the process, too.) Think of it > this way: there's a certain beauty in surgery, but autopsies > just stink. Yes, I certainly agree. I'm not running V8 on my machine, but I can do this too. (We don't even have "/proc", but we do have some additions to "ptrace". Of course, it would be possible to implement "/proc" here using the "virtual file system" mechanism that the UNIX file system and the NFS file system are plugged in to.) Besides, autopsies may be a pain, but if someone wheels a corpse into your office and asks you what the cause of death is, you don't have much choice. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
shannon@sun.uucp (Bill Shannon) (04/07/86)
John Mackin claims that it is a "bad thing" that some programs had to be modified when job control was introduced. Guy Harris pointed out that only a small handful of programs needed to be modified, very few of them simple user programs. While window systems solve many of the same problems that job control solves (in most cases with much better solutions than with job control), they also introduce new problems, just as job control did, because they break some basic assumptions in programs. One of the most basic assumptions broken by window systems is that a terminal has a fixed number of lines and columns. With a window system, the number of lines and columns in the "terminal" (i.e. window) can vary dynamicly, even while the program is running. To better accomodate this change, it is often desirable (and sometimes necessary) to modify some programs to react to window size changes. Just as with job control, we would prefer not to modify any programs. Yet the fact that we do modify some programs does not mean that there is something inherently wrong with either job control or window systems. Bill Shannon
karl@osu-eddie.UUCP (Karl Kleinpaste) (04/07/86)
In article <2350@brl-smoke.ARPA> gwyn@brl.ARPA writes: >In article <559@basser.oz> john@basser.oz (John Mackin) writes: >>In article <127@sering.mcvax.UUCP> dpk@sering.UUCP (Doug Kingston) writes: >>> [omitted] > >>A Blit is a research terminal, manufactured first at Bell Research >>and then by Teletype exclusively for Bell Research. > >Another significant difference between the Blit and the 5620 would seem >to be the color of the display; didn't the Blit have a white phosphor? No. They have green phosphor screens, too. However, old-style Blits were stuck with nothing but black-on-green, whereas 5620s have a setup menu selection to pick black-on-green or green-on-black. I can't take a mostly-green screen for any length of time; everything looks red when you look away from the terminal, and depending on how long you were staring at your terminal, that redness can stick with you for quite some time. This is especially true in the early morning for me; by late afternoon, my eyes are so frazzled that they don't care what they see any more. -- Karl Kleinpaste
wjb@goanna.OZ (Warwick Bolam) (04/08/86)
> In article <127@sering.mcvax.UUCP> dpk@sering.UUCP (Doug Kingston) writes: > > > I use BLIT terminals and SUN-like > > workstations every day. However, this does not mean I want to give > > up the ability to STOP and RESTART jobs. [...] > > [...] > > In summary, look at the broader uses of BSD job control before condemning > > its usefulness. Its not just for allowing simultaneous processing. [...] All the discussion of what a hack job control is and how it imitates a windows system and hence should be thrown away is a bit annoying to those of us using 80*24 character terminals. One day we'll all have Suns or 5620's, or something similar. Until then, job control is a *very* useful hack. Warwick Bolam Dept of Computing Royal Melbourne Institute of Technology Melbourne, Victoria AUSTRALIA seismo!munnari!goanna.oz!wjb Usenet munnari!goanna.oz!wjb@SEISMO.ARPA ARPANET
tim@ism780c.UUCP (Tim Smith) (04/09/86)
In article <3460@sun.uucp> shannon@sun.uucp (Bill Shannon) writes: > One of the most basic assumptions broken by window systems is > that a terminal has a fixed number of lines and columns. With a > window system, the number of lines and columns in the "terminal" > (i.e. window) can vary dynamicly, even while the program is > running. To better accomodate this change, it is often desirable > (and sometimes necessary) to modify some programs to react to > window size changes. I think that a window should have both a logical and a physical size. When the user resizes a window, that would only change the physical size - the logical size would stay the same. If the physical size is smaller than the logical size, the windowing system should put in scroll bars. Programs need not know that the physical size has changed. Programs that want to know the physical size would be able to ask, but programs written for terminals with fixed sizes would still work. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
dennis@utecfc.UUCP (Dennis Ferguson) (04/09/86)
In article <559@basser.oz> john@basser.oz (John Mackin) writes: > [...] I am typing this on a Blit. We have > an Eighth Edition license and Bell Research have donated 12 > Blits to us. The Teletype DMD5620 can be unambiguously > referred to as: a 5620 (probably best) [....] I am typing this on a rather dumb 24x80 terminal. Approximate value is $400. I have showed your message to just about everyone around here with funds but no one has volunteered to provide me with the $9000 or so I would need to buy a 5620. Some people have all the luck. > Now that I've got that out of the way, let's go on to discuss > so-called job control. The whole point about Berkeley job control > is, it is a massive hack. Witness the huge number of user-mode > programs that had to be modified to know about SIGTSTP, etc. > Not to mention the far-reaching kernel modifications [...] For the latter, you might try obtaining 4.1BSD kernel sources and diff'ing the parts of it which implement signals and the starting and stopping of processes with the corresponding parts of your V8 kernel. I'll bet you will be surprised at the small amount of output you get. As for user-mode programs, I just did a `grep TSTP' on files in the directories /usr/src/{bin,usr.bin,usr.ucb} on this 4.2 system. The programs I found sort of divide themselves into three categories. The biggest group are those that explicitly ignore SIGTSTP, usually along with SIGQUIT and SIGINT. These are login, passwd, msgs, chfn, chsh and lock. The second were those that use SIGTSTP instead of, or as well as, a shell escape. These are rlogin, telnet and tip. Finally there are those which restore their screen in some way after a SIGTSTP. These are ex/vi and more (note that the curses library catches SIGTSTP so full-screen programs which use that library generally don't bother about it). And of course there is csh, stty and kill, but that is about it. I really don't know how you decided a "huge number of user-mode programs" had to be modified, as far as I can see only a small percentage of user-mode software from Berkeley worries about it at all, and most of these programs simply ignore it for security reasons. > You say as much, but then you say you still want to be able to > stop and restart processes. On V8, that is as easy as opening > the process' /proc entry and doing a single ioctl(). No harder > than doing a kill(). This is one way to use the ability to stop and restart processes which Berkeley (or, actually, Jim Kulp at IIASA) implemented in their kernel and V8 inherited. ^Z is another, very different one. I (unlike the person you were replying to) have no doubt that a good window system effectively eliminates the need for a suspend character (and interrupt and quit (! a key to cause a core dump? If ^Z was a hack, it had precedent)). Note, however, that Berkeley job control was implemented in 1980 or thereabouts, when window systems were at most exotic research projects. It was certainly never intended to be a replacement for window systems; it is their predecessor. What ^Z is is a replacement for *its* predecessor, the shell escape. A shell escape requires code in each program which implements it. It is also not possible to implement a shell escape at all in many programs in which it would be desirable (e.g. compilers). The suspend character provides a uniform, centralized, transparent (relative to actual shell escapes) facility which obsoletes the shell escape. As such it was successful. Of course, window systems may have now made obsolete the suspend character. And if you send me one of your windowing terminals I will gladly turn it (and probably the quit character) off for good. Until then, as long as I am forced to use less able technology, I will stick with it, thanks. Even, incidentally, if I am using V8, seeing as the implementor thought to retain it in the (streams) terminal handling code. -- Dennis Ferguson (...!utzoo!utcsri!utecfc!dennis) Mechanical Engineering University of Toronto
scott@cstvax.UUCP (Scott Larnach) (04/10/86)
> job control is a massive hack
... not the point. The point being, is it useful? The answer being,
yes, very.
--
** REPLACE THIS NETWORK WITH A BAGFUL OF MAGTAPE **
Scott Larnach Janet: scott@uk.ac.ed.itspna
Edinburgh Unix Support Arpa: scott@itspna.ed.ac.uk
Tel: +44 31 667 1081 x2629 Uucp: scott@cstvax.uucpcsg@pyramid.UUCP (Carl S. Gutekunst) (04/11/86)
In article <559@basser.oz> john@basser.oz (John Mackin) writes: >Well. First of all let's split some hairs. [Please note that I'm >not attacking you or your posting, but I do value correctness... >ok, I'm pedantic.] > >... The Teletype DMD5620 is a commercial product. >It has a WE32000 cpu and 256K of ram which can be expanded to 1M. Pedantic? Then you'll want to know that the current DMD5620 uses a WE32100. It does make a difference, and can be a real pain at times.... -- Carl S. Gutekunst {allegra,cmcl2,decwrl,hplabs,ut-sally,utzoo}!pyramid!csg Pyramid Technology Corp, Mountain View, CA +1 415 965 7200
tim@ism780c.UUCP (Tim Smith) (04/12/86)
In article <71@utecfc.UUCP> dennis@utecfc.UUCP (Dennis Ferguson) writes: > >I am typing this on a rather dumb 24x80 terminal. Approximate >value is $400. I have showed your message to just about everyone >arund here with funds but no one has volunteered to provide me >with the $9000 or so I would need to buy a 5620. Some people have >all the luck. > There is no reason one can not make 5620 technology available at a very low cost. Look at some of the computers that are now available with bitmapped displays: Macintosh ( 512k goes for around $1300 ), Atari 520ST ( $800 ), and Amiga ( ~$1200? ). There is no reason one can not turn any of these into a reasonable 5620 emulator. The large screen of the 5620 is nice, but I think one could live with the smaller screens of the above computers. Anyone care to predict how long the dumb terminal will last? Unless it is real cheap ( i.e., almost free ), I can't see any reason to get one when for maybe twice as much I can get a computer and run a terminal emulator. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
mac@tflop.UUCP (Mike Mc Namara) (04/12/86)
In article <> dennis@utecfc.UUCP (Dennis Ferguson) writes: >In article <559@basser.oz> john@basser.oz (John Mackin) writes: >> [...] I am typing this on a Blit. We have... > >I am typing this on a rather dumb 24x80 terminal. Approximate >value is $400. > ... > >Of course, window systems may have now made obsolete the suspend character. >And if you send me one of your windowing terminals I will gladly turn it >(and probably the quit character) off for good. Until then, as long as Especially if you were only *loaning* the terminal to me!! /// \\\\ ><<<SMASH>>>>< (the terminal is `off for good') \\\ //// >I am forced to use less able technology, I will stick with it, thanks. >Dennis Ferguson (...!utzoo!utcsri!utecfc!dennis) Now, I happen to have a sun & a wyse 50 on my desk, and I use the wyse 50 'cause the keyboard is much nicer... (of course the sun is a 100U...) mac@tflop
guy@sun.uucp (Guy Harris) (04/12/86)
> I think that a window should have both a logical and a physical size. > When the user resizes a window, that would only change the physical > size - the logical size would stay the same. If the physical size is > smaller than the logical size, the windowing system should put in > scroll bars. OK, imagine a text editor. Assume that the logical size is the maximum size of a window. You use the scroll bars to slide the physical window over the logical window. Now what if you want to scroll the *editor's* window into the *file*? Can you use the same scroll bars? I suspect it can be done, but make sure your whizzo window system can do this. So much for vertical scrolling. What about horizontal scrolling? I happen to prefer an editor which truncates lines at the margin, rather than wrapping them, but some people may prefer wrapping. Such an editor has to know about the physical size of the screen - wrapping at the boundary of the logical screen seems a bit silly. What about a system which displays a fixed amount of data - say N rows by M columns of text, or a drawing of a certain size? Such a system might very well want to scale this display to the size of its window, so that you can blow the display up by stretching the window. (The Andrew system's terminal emulator, which emulates a 24x80 Heath H19 terminal, does exactly that.) What about a program which has a display consisting of a main display subwindow, a command line, and a messages line, or something similar? (For two obscure little-used programs which use the screen in this way, let's pick "vi" and EMACS.) If I start up EMACS (or "vi") in a full-height window, and then shut that window down to the Sun standard 34x80, your scheme might very well put EMACS' status line and command/messages line (mode line and minibuffer) outside the window. This seems silly. It would make more sense to have the main display window be resized by EMACS, which is exactly what does happen on a Sun. I'm afraid this sounds like the putative benefits of not having something like SIGTSTP - you might say that you "don't have to" modify programs to know about being suspended, or having their window size changed, but what this really means is that you *can't* modify programs to know about this, even if doing so would give them a better user interface. Sorry, but any system that buys "conceptual elegance" at the expense of making the person who uses the system had better be a LOT more conceptually elegant than a system which is more pleasant to use if it's to interest me - especially if I'm the person who has to use it. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
mike@peregrine.UUCP (Mike Wexler) (04/15/86)
In article <3493@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> I think that a window should have both a logical and a physical size. >> When the user resizes a window, that would only change the physical >> size - the logical size would stay the same. If the physical size is >> smaller than the logical size, the windowing system should put in >> scroll bars. I agree to some extent. > >OK, imagine a text editor. Assume that the logical size is the maximum size >of a window. You use the scroll bars to slide the physical window over the >logical window. Now what if you want to scroll the *editor's* window into >the *file*? Can you use the same scroll bars? I suspect it can be done, >but make sure your whizzo window system can do this. Yes. So much for transparency. I guess you could just send the generic scroll key. What? You say there is no such thing. Uh oh. > >So much for vertical scrolling. What about horizontal scrolling? I happen >to prefer an editor which truncates lines at the margin, rather than >wrapping them, but some people may prefer wrapping. Such an editor has to >know about the physical size of the screen - wrapping at the boundary of the >logical screen seems a bit silly. How about windows having attributes such as whether the physical window size and logical window size are bound together. The window system good have a list of programs and what default attributes they override. > >What about a system which displays a fixed amount of data - say N rows by M >columns of text, or a drawing of a certain size? Such a system might very >well want to scale this display to the size of its window, so that you can >blow the display up by stretching the window. (The Andrew system's terminal >emulator, which emulates a 24x80 Heath H19 terminal, does exactly that.) Yet another attrbiute(YAA). > >What about a program which has a display consisting of a main display >subwindow, a command line, and a messages line, or something similar? (For >two obscure little-used programs which use the screen in this way, let's >pick "vi" and EMACS.) If I start up EMACS (or "vi") in a full-height >window, and then shut that window down to the Sun standard 34x80, your >scheme might very well put EMACS' status line and command/messages line >(mode line and minibuffer) outside the window. This seems silly. It would >make more sense to have the main display window be resized by EMACS, which >is exactly what does happen on a Sun. How about multiple windows? Transparency? Whats that? > >I'm afraid this sounds like the putative benefits of not having something >like SIGTSTP - you might say that you "don't have to" modify programs to >know about being suspended, or having their window size changed, but what >this really means is that you *can't* modify programs to know about this, >even if doing so would give them a better user interface. Sorry, but any >system that buys "conceptual elegance" at the expense of making the person >who uses the system had better be a LOT more conceptually elegant than a >system which is more pleasant to use if it's to interest me - especially if >I'm the person who has to use it. Such a system could actually be pleasant to use, if it was designed and implemented well. Wouldn't it be nice if the same scroll commands worked in Emacs(vi/fnorkel 2) and Suntools? Wouldn't it be nice if Emacs(or others) had overlapping and closable windows? Have you ever wanted to scroll backwards in a line oriented program(to see what did 45 seconds ago)? Have you ever had a program that needed 132 characters? Wouldn't it be nice to be able to resize the window *AFTER* you run it and see the input spread across the screen. My point is that the proposed system, although it would be very difficult to implement might be quite a bit more pleasant to use then what is currently available. -- Mike Wexler (trwrb|scgvaxd)!felix!peregrine!mike (714)855-3923
philip@axis.UUCP (Philip Peake) (04/16/86)
In article <1586@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >In article <71@utecfc.UUCP> dennis@utecfc.UUCP (Dennis Ferguson) writes: >> >>I am typing this on a rather dumb 24x80 terminal. Approximate >>value is $400. I have showed your message to just about everyone >>arund here with funds but no one has volunteered to provide me >>with the $9000 or so I would need to buy a 5620. Some people have >>all the luck. >> > >There is no reason one can not make 5620 technology available at a >very low cost. I find the cost of 5620's interresting. I know its not exactly the same thing as a Blit, but the following extract seems worth thinking about.. "The Blit is inexpensive. For little more than the cost of replacing the 24-by-80 terminals, everyone in our research center, including the support staff, has a Blit." This quote is taken from the BLTJ, Vol.63, "The Blit: A multiplexed graphics terminal" So, who is making the big fat profit (as if you couldn't guess) ?
tim@ism780c.UUCP (Tim Smith) (04/16/86)
In article <3493@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> I think that a window should have both a logical and a physical size. >> When the user resizes a window, that would only change the physical >> size - the logical size would stay the same. If the physical size is >> smaller than the logical size, the windowing system should put in >> scroll bars. > >OK, imagine a text editor. Assume that the logical size is the maximum size >of a window. You use the scroll bars to slide the physical window over the >logical window. Now what if you want to scroll the *editor's* window into >the *file*? Can you use the same scroll bars? I suspect it can be done, >but make sure your whizzo window system can do this. > >So much for vertical scrolling. What about horizontal scrolling? I happen >to prefer an editor which truncates lines at the margin, rather than >wrapping them, but some people may prefer wrapping. Such an editor has to >know about the physical size of the screen - wrapping at the boundary of the >logical screen seems a bit silly. > I didn't mean that programs should not be able to find out the size of a window, and when it changes. I meant that if a program doesn't say to the windowing system, "Hey man, I'm a whiz bang program, and I won't freak if my window changes size", then the windowing system should keep track of a logical and physical size of the window. If a program tells the windowing system that it is a whiz bang program, then the program would be informed of size changes, and there would be no difference between the logical and physical window. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
gwyn@brl-smoke.UUCP (04/16/86)
In article <1586@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >In article <71@utecfc.UUCP> dennis@utecfc.UUCP (Dennis Ferguson) writes: >>I am typing this on a rather dumb 24x80 terminal. Approximate >>value is $400. I have showed your message to just about everyone >>arund here with funds but no one has volunteered to provide me >>with the $9000 or so I would need to buy a 5620. The last price I could find for a 5620 is $3300, $3000 for the Core host software (which applies to any number of 5620s on the host), $2000 for the Text+Graphics software. (These prices have probably come down a bit in the meantime.) It is more cost-effective to have several DMDs on the same host than to have just one. The asymptotic average price of a 5620 was $3300, not even allowing for quantity discounts. I don't want to make this into a commercial, but the $9000 figure is misleading. >There is no reason one can not make 5620 technology available at a >very low cost. Look at some of the computers that are now available >with bitmapped displays: Macintosh ( 512k goes for around $1300 ), >Atari 520ST ( $800 ), and Amiga ( ~$1200? ). > >There is no reason one can not turn any of these into a reasonable >5620 emulator. The large screen of the 5620 is nice, but I think one >could live with the smaller screens of the above computers. The 5620 does far more than provide windows. There is a large amount of work involved in developing the cross-SGS, libraries, etc. Indeed, I've had to do considerable work just to port the existing code to a new host. (To be fair, I should admit that much of this work should not have been necessary if portable coding practices had been used and if the target host had had a better C compiler.) Similar software using Macs etc. would be nice, all right, but providing it is not a trivial task. Looks like a viable commercial product idea to me.. >Anyone care to predict how long the dumb terminal will last? Unless >it is real cheap ( i.e., almost free ), I can't see any reason to get >one when for maybe twice as much I can get a computer and run a terminal >emulator. My Branch has quit buying dumb terminals. I don't see much advantage in using something like an IBM PC as a terminal emulator (unless you happen to already have one), but the Blit/DMD (Xerox, Sun, etc.) approach is another story.
friesen@psivax.UUCP (Stanley Friesen) (04/18/86)
In article <1835@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: > >I didn't mean that programs should not be able to find out the size of >a window, and when it changes. I meant that if a program doesn't say >to the windowing system, "Hey man, I'm a whiz bang program, and I >won't freak if my window changes size", then the windowing system >should keep track of a logical and physical size of the window. > >If a program tells the windowing system that it is a whiz bang program, >then the program would be informed of size changes, and there would be >no difference between the logical and physical window. Actually, under UNIX the way to do this is have the windowing system send some standard signal, say SIGWINCH, to the process whose window is being changed. The default action fo this signal would of course be to *ignore* it. If a process wants/needs to know about window changes it can arrange to catch the signal! This is consistant with the rest of the UNIX OS and is operationally equivalent to what you are talking about, since a program that doesn't need to know can simply do nothing at all. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
friesen@psivax.UUCP (Stanley Friesen) (04/21/86)
In article <59@brl-smoke.ARPA> gwyn@brl.ARPA writes: > >The last price I could find for a 5620 is $3300, >$3000 for the Core host software (which applies >to any number of 5620s on the host), $2000 for >the Text+Graphics software. > >In article <1586@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >>Anyone care to predict how long the dumb terminal will last? Unless >>it is real cheap ( i.e., almost free ), I can't see any reason to get >>one when for maybe twice as much I can get a computer and run a terminal >>emulator. > They will last until the price of a BLIT or 5620 is < $1000, since that is what it will take for less rich firms to start buying them for ordinary users. Really $3000 is *not* cheap! -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa
tim@ism780c.UUCP (Tim Smith) (04/22/86)
In article <1106@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: > > Actually, under UNIX the way to do this is have the windowing >system send some standard signal, say SIGWINCH, to the process whose >window is being changed. The default action for this signal would of >course be to *ignore* it. If a process wants/needs to know about >window changes it can arrange to catch the signal! This is consistant >with the rest of the UNIX OS and is operationally equivalent to what >you are talking about, since a program that doesn't need to know can >simply do nothing at all. I don't think that this is equivalent to what I want. I want there to be two types of procs: those that know about windows, and those that don't. Those that do would be told about window changes, probably with a signal. Those that don't would not know that they are on a windowing system. Their window would look like a terminal. When the user does something like change the size of the window, that would not change the logical size of the window, just the physical size. [ by the way, I am assuming a windowing system that keeps track of what is obscured by other windows, not one that requires procs to redraw their own screens. Thus, the only window changes that a proc should care about are size changes ( and deletions... ) ] Note that under this scheme I should be able to take vi or rogue, and run them with no changes at all. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
tim@ism780c.UUCP (Tim Smith) (04/22/86)
In article <59@brl-smoke.ARPA> gwyn@brl.ARPA writes: >> >>There is no reason one can not turn any of these into a reasonable >>5620 emulator. The large screen of the 5620 is nice, but I think one >>could live with the smaller screens of the above computers. > >The 5620 does far more than provide windows. There is a large amount >of work involved in developing the cross-SGS, libraries, etc. >Indeed, I've had to do considerable work just to port the existing >code to a new host. (To be fair, I should admit that much of this >work should not have been necessary if portable coding practices >had been used and if the target host had had a better C compiler.) > Amen on portable coding practices! Yes, lot's of 5620 stuff would not be easy to deal with ( proof and jim come to mind ... ), but I think one could get a lot of the 5620s advantages at a reasonable cost. I define reasonable cost as that which I can convince the company to spend. :-( >>Anyone care to predict how long the dumb terminal will last? Unless >>it is real cheap ( i.e., almost free ), I can't see any reason to get >>one when for maybe twice as much I can get a computer and run a terminal >>emulator. > >My Branch has quit buying dumb terminals. >I don't see much advantage in using something like an IBM PC >as a terminal emulator (unless you happen to already have one), >but the Blit/DMD (Xerox, Sun, etc.) approach is another story. The problem I have with the 5620 is that for the price, I can get a Mac or an Amiga or an Atari 1040ST, a hard disk, software, etc, and have something to play with when the VAX is down. With a 5620 all I can do is run diagnostics, which gets stale after a few hours! :-) Next year for the price of a 5620, I hope to be able to get a 68020 based Mac or Amiga or Atari, which would probably have as much power as the fraction of the VAXes time that gets devotes to me. Then it starts to get hard to justify the cost. Now if they would put a hard disk on the 5620... -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
tim@ism780c.UUCP (Tim Smith) (04/22/86)
In article <1114@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >> >>Anyone care to predict how long the dumb terminal will last? Unless >>it is real cheap ( i.e., almost free ), I can't see any reason to get >>one when for maybe twice as much I can get a computer and run a terminal >>emulator. > > They will last until the price of a BLIT or 5620 is < $1000, >since that is what it will take for less rich firms to start buying >them for ordinary users. Really $3000 is *not* cheap! Have you seen the 1040ST? Price < $1000, and it should be able to be turned into a quite nice terminal. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
friesen@psivax.UUCP (Stanley Friesen) (04/22/86)
In article <1918@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >In article <1106@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes: >> >> Actually, under UNIX the way to do this is have the windowing >>system send some standard signal, say SIGWINCH, to the process whose >>window is being changed. The default action for this signal would of >>course be to *ignore* it. > >I don't think that this is equivalent to what I want. I want there to >be two types of procs: those that know about windows, and those that >don't. Those that do would be told about window changes, probably >with a signal. Those that don't would not know that they are on >a windowing system. Their window would look like a terminal. EXACTLY, that is why the default action for SIGWINCH is *ignore*, that way a program that doesn't care need not even know about it! By simply doing nothing it gets nothing, it doesn't even really recieve the signal, it gets thrown away by the kernel. Thus the manager program(the multiplexor or meta-shell) need not know which programs want to know about changes, it can just send the signal all the time and let the processes that want to know arrange, by explicit action, to catch and process the signal. In short arranging to catch SIGWINCH is equivalent to notifying the kernel "I want to know about window changes". > When >the user does something like change the size of the window, that would >not change the logical size of the window, just the physical size. Certainly. > >[ by the way, I am assuming a windowing system that keeps track of what > is obscured by other windows, not one that requires procs to redraw > their own screens. Thus, the only window changes that a proc should > care about are size changes ( and deletions... ) ] > Absolutely. Well, deleting a window attached to a running process should be *rare*, maybe this should send a SIGHUP, since it is logically equivalent to unplugging a terminal. >Note that under this scheme I should be able to take vi or rogue, and >run them with no changes at all. And under mine as well, if it is implemented correctly. As I said, a process that doesn't care simply does nothing and the kernel silently and transparently ignores SIGWINCH. The program never even knows it has been sent. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa