Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!newstop!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.atari.st Subject: Re: Rebuttal time Message-ID: <124630@sun.Eng.Sun.COM> Date: 13 Sep 89 18:10:15 GMT References: <8908252144.AA27005@ucbvax.Berkeley.EDU> <123950@sun.Eng.Sun.COM> <500@nixpbe.UUCP> Sender: news@sun.Eng.Sun.COM Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 89 In article <500@nixpbe.UUCP> mboen@nixpbe.UUCP (Martin Boening) writes: ->cmcmanis%pepper@Sun.COM (Chuck McManis) writes: ->> .... ->>The keys are that you have to have a _window based_ UI because single ->>interface terminal UI's are generally not flexible enough for effective ->>use of multitasking .... -> ->Come again? I suppose most UNIX Systems then aren't really effective ->doing multitasking, what with all those stupid single interface terminal ->UI's called vt100 terminals. You managed to yank my comments completely out of context but you make the same point I made in my original article. You comment above is misguided though. The point I make is not that UNIX or any other multitasking OS is effective in what it does, but that for a single user to make the _most_ use of multitasking requires some sort of GUI. (Graphic User Interface) ->The idea is: multitasking is nice but you don't need window-based UI's. ->E.g. I start a make in the background, push whatever else comes to mind ->(such as some net statistics programs, TeX runs, etc.,into the background ->and then do some edditing in the foreground. For this, I don't necessarily ->need a window-based UI. Your right you don't, and you don't even need "true" multitasking either because any number of hacks would let you do the same. The key though is that you will notice you only have *one* interactive application running at a time on your VT100 because you can't *get* to any others. ->Same goes for multitasking on personal computers (let's avoid saying PC ->here, it's a much abused term :-)). It's nice to have a window_based UI ->(such as on the Amiga, but also such as MS-Windows!), but it's no neces- ->sity. This is especially true if all you do in the background is print ->spooling, disk formatting and compiling. What else do you do in the ->background? To have 10 editor sessions, you hardly need multitasking. ->All you need is TASK SWITCHING, because there's no concurrent processing ->involved. Ray tracing? Have it trace into a file which you can view later. ->Who cares to see a ray trace image SLOOOWLY unfold in a separate window ->while editing? Whoi can even look at that separate window between looking ->at the edit window and the text he (she) is typing. I left this text intact because it is pretty effective at making the point I tried to make. For the kinds of operations you mentioned you don't need multitasking at all, switching works just fine. What you apparently realize but don't mention is that if you want to run several *INTERACTIVE* applications at the same time there must be some way for you to identify which interactive application you are interested in communicating with *at a particular point* in time. Take as a contrived example, editing a document, possibly a response to an online debate, while watching that debate going on. This happens on any conferencing system such as BIX or CompuServe that has a "forum" type mode where several people can make comments in "real time". Generally to your "terminal" session this appears as a bunch of lines like : [joe-bob] Did you see Friday the 13th Part XXIV? [frieda] No, what was the plot? [joe-bob] What's a plot? These display the comments and their authors. In the editor you will want to type your response and then when it is ready squirt it out to the serial line. But it is _more effective_ to be able to watch what is going on while you are composing because you might otherwise seem foolish if your response echoes several previous responses. Another contrived example which is closer to home, suppose you were creating a video on your system. You have rendered the animation and now you want to add music and sound effects. Well you need to run both the sound effects editor/designer and the animation program at the same time. Primarily so that you can note frames in the animation, add sounds continue with the animation, play it back, repeat. You _could_ do this with task switching and a notepad, but it would be _more effective_ if you could run both on the screen at the same time. It certainly isn't a black and white issue, but the areas of interest are that "true" multitasking [which is defined to occur when every application running under the OS is the same whether it runs by itself or with another application] gives you the ability to have both *applications* running simultaneously, and the GUI lets you interact with them on the same screen. So if I could boil the point down to it's barest essentials it would be "A major benefit of multitasking is more effective use of the systems resources, and a major benefit of GUIs is more effective use of multitasking." --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "If I were driving a Macintosh, I'd have to stop before I could turn the wheel."