01659@AECLCR.BITNET (Greg Csullog) (08/26/89)
>in article <8908160401.AA01009@ucbvax.Berkeley.EDU>, 01659@AECLCR.BITNET (Greg >Csullog) says: >> Look, I can format floppies from within all my ST applications, >But you have to either have the Format command available as a desk accessory >(don't know if it's possible?), or each individual program must worry about >including a disk format option. Certainly if that's important to the market, >most will, but it's still something a program's author shouldn't have to >worry about -- debugging the real application should occupy all their time. >Plus, when I format a floppy, I can click back to my WordProcessor or >Terminal or whatever else I have running, while the format takes place. Obviously, you are not aware of the Universal Item Selector for the ST. Yes, I agree it's not fun to wait to format a floppy and being able to do another task at the same time would be helpful. However, is this REALLY the key factor in having a multitasking system? Surely not! In eight years of using micros (HP, PC, DEC, ST, Mac) I cannot recall more than 5 or 6 times I had to format a floppy while running an application and when I had to, with the UIS for example, I had to wait for the floppy to be ready to continue my work - that's why I formatted it! I was not willing to jump to another application just so I could kill one minute. >> I can run a word processor, a spreadsheet and a painting program at the same >> time and switch between them. >But you can't have the word processor ask the data base to find you client >files, extract some data, pass it to the spreadsheet, generate a color >image, then pass that to the paint program for conversion to black and >while, before being inserted into your word processor. You need several >programs active for that kind of interaction. Obviously, you are not familiar with REVOLVER either. On one occasion, I was using LDW (a LOTUS clone) and dbMAN (a dBASE III plus clone) at the same time. I run a small VAR dealership selling STs and I have some data on a spread- sheet and some on a database. These applications were in different memory partitions while I compared data as I switched between them. I extracted data from the sheet, passed it to a common RAM disk for the partitions and imported the info into the database. Then, from a third partition, where I was running my word processor, I read in the extracted data to include it in a tax report I was preparing. If I wanted, I could have just as easily run either my DTP or a graphics program in another partition to share data via the RAM disk. BUT, I was doing task switching, NOT multitasking as each application is suspended as I switch partitions. However, it's no big deal in this instance as each application I switch out of does not have to do anything after I switch out. REVOLVER also has another great feature. I can roll out a 1 meg partition from RAM to about 300K on disk. In effect, the application is frozen on disk and when rolled back in, I can pick up exactly where I left off. As such, I can roll many applications in and out (and quickly) to free me of some of the restrictions that are imposed by available memory and are only over- come using virtual memory. Still more on REVOLVER. Suppose I am programming in one partition while another application sits in another. Whoops, I crash my ST because my code is buggy. No problem, the common RAM disk stays intact and ONLY THE PARTITION THAT CRASHED NEEDS TO BE REBOOTED. The other partition(s) remain unaffected as if I had two or more STs side by side. Now that's the kind of stuff I like! >>BUT, when I want to crank out dbMAN reports from my databases (one is >>almost 4 megabytes), I don't want to slow down my 68000 by using another >>application at all. I want the dbMAN stuff out asap. >DataBase stuff is often disk intensive. If my DB program is thumbing through >100 megs of database to prepare a report, I'll likely have lots of CPU time >left for other stuff. Not in my case, I do a lot of number crunching in conjunction with data look ups based on search conditions. I have imported my dBASE III work from my AT at work to my ST because dbMAN is faster in the same job. We have dBASE IV at work that is faster to use once codes are developed and compiled but ASHTON-TATE has taken a giant step backwards in its user interface for IV. The whole thing is more cumbersome and much slower than III's interface.
f-leoe@IFI.UIO.NO (LarsErik0sterud) (08/26/89)
There are two problems with UIS II: 1) Its not public domain and you have to buy it.. 2) It does not (as far as I know) format disks that can be read on IBM's in the same way as TOS 1.4 does..... Lars-Erik 0sterud / Call ABK-BBS / ____ ______ f-leoe@ifi.uio.no / +47 2 132659 / /___ / ____________________/ _______________/ ____/ /
cmcmanis%pepper@Sun.COM (Chuck McManis) (08/30/89)
In article <8908252144.AA27005@ucbvax.Berkeley.EDU> (Greg Csullog) writes: > However, is this REALLY the key factor in having a multitasking system? > Surely not! In eight years of using micros (HP, PC, DEC, ST, Mac) I > cannot recall more than 5 or 6 times I had to format a floppy while > running an application ... What this statement essentially says is that you have no relevant experience to relate to the issues. Nothing personal but unless you are talking about the HP2100 or the Dec PDP 11, none of the systems you have had experience with supports multitasking with it's native OS. Why can't someone just pipe up and say "I'm using a _window system based_ multitasking OS right now, and I a) don't like it, or b) am not using it as one nor do I ever use it as one." 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 and there has to be other programs that _know_ your OS is multitasking so that they can take advantage of it if they choose to. These two requirements eliminate every single "micro" (except the Amiga) from the test. I could go into why these two requirements are so important for a proper test, but that would just add to the noise I suspect. Ok, so we've heard from the Amiga users who say (paraphrased) : "Multitasking is great, your full of Bat Guano if you don't agree." And we've heard from ST/PC/Mac users who have said (paraphrased) : "I don't need no stinking multitasking, it's about as useful as jet engines on a baby carriage." Lets see if we can find those silent individuals who can present the opposing cases. These would be the Amiga user who is saying : "This multitasking stinks, every time I turn around it has made my life miserable." and the ST/Mac/PC user who is saying : "You know, if only I had a multitasking OS, this is what I could accomplish." Thanks for listening, --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."
landay@cory.Berkeley.EDU (James A. Landay) (08/30/89)
In article <123950@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >Lets see if we can find those silent individuals who can present the >opposing cases. >and the ST/Mac/PC user who is saying : > "You know, if only I had a multitasking OS, this is what > I could accomplish." > >Thanks for listening, >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com I am an Atari ST user. I would love to have a multitasking OS, because I KNOW what kind of stuff I can do with it (from using Unix, X, Suns, etc.) Anyone who says otherwise must not have had much experience with multitasking OSs. James A. Landay ARPA: landay@cory.berkeley.edu ..!ucbvax!cory!landay
jlemon@cory.Berkeley.EDU (Jonathan Lemon) (08/30/89)
In article <16658@pasteur.Berkeley.EDU> landay@cory.Berkeley.EDU.UUCP (James A. Landay) writes: }In article <123950@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: }>Lets see if we can find those silent individuals who can present the }>opposing cases. }>and the ST/Mac/PC user who is saying : }> "You know, if only I had a multitasking OS, this is what }> I could accomplish." }> } }I am an Atari ST user. I would love to have a multitasking OS, because I }KNOW what kind of stuff I can do with it (from using Unix, X, Suns, etc.) } }Anyone who says otherwise must not have had much experience with }multitasking OSs. Me too. I would really like multi-tasking on my mega! In the end, I had to decide that the other little advantages of the Mega outweighted the multi-tasking of the Amiga. (at least for my case) -- Jonathan ...ucbvax!cory!jlemon jlemon@cory.Berkeley.EDU Newsgroups: comp.sys.atari.st Subject: Re: Rebuttal time Summary: Expires: References: <8908252144.AA27005@ucbvax.Berkeley.EDU> <123950@sun.Eng.Sun.COM> <16658@pasteur.Berkeley.EDU> Sender: Reply-To: jlemon@cory.Berkeley.EDU.UUCP (Jonathan Lemon) Followup-To: Distribution: Organization: University of California, Berkeley Keywords:
jlf@a.cs.wvu.wvnet.edu (Jack L Forester) (08/30/89)
I have been using the Beckmeyer MT C-shell for better than three years now.
I have had my share of problems with it, but overall, I like it and I *use*
it. (BTW if anyone knows where I can get info on upgrades, please let me
know).
I tried to use Gulam, but after playing with it, I erased it from my hard
disk and concluded that I liked the Beckmeyer system better.
-- I like the print spooler. I know that there are DAs out there that will
almost do this same thing, and that it tends to be a bit slow, but it's
still better than anything else I've seen. I don't know of other print
spoolers that allow multiple documents to be spooled.
-- *It's MULTIUSER* Not that I intend to sell time on my ST, but it allows me
to log into my computer from a remote site and do whatever I need to do.
-- The mail function allows my friends to get in touch with me when I'm not
around. I give them a userid so they can log in and post mail.
-- It works like UNIX. When I came here to WVU I had no problem working
on our departmental Vax systems.
Sure, it has it's problems (no true memory protection, no file security
system, etc.) the benefit of multitasking and the other things I mentioned
give me enough reason to use it.
My experiences on multiuser, multitasking range from my ST, some midrange
minicomputer systems all the way up to the largest IBM mainframes. So I
speak from experience when I say that I prefer multitasking over
unitasking.
Now I am sure that there are those who will try to impugn me for my choice
of multitasking systems. This is not possible. I weighed my options and
chose the system that best fits *ME*, not someone else. (That's why I chose
the ST over all of the other computers on the market.) If you don't like my
choice, that's fine. That's also *your* opinion.
{$I disclaimer}
jlf@a.cs.wvu.wvnet.edu
"Profanity is the one language all programmers know best."dav@eleazar.dartmouth.edu (William David Haas) (08/31/89)
In article <16658@pasteur.Berkeley.EDU> landay@cory.Berkeley.EDU.UUCP (James A. Landay) writes: >In article <123950@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >I am an Atari ST user. I would love to have a multitasking OS, because I >KNOW what kind of stuff I can do with it (from using Unix, X, Suns, etc.) > >Anyone who says otherwise must not have had much experience with >multitasking OSs. What he said.
rex@otto.UUCP (Rex Jolliff) (08/31/89)
In article <123950@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: > >and the ST/Mac/PC user who is saying : > "You know, if only I had a multitasking OS, this is what > I could accomplish." >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com How about, I have a multitasking OS for the ST, but it doesn't do what I would like it to. I have Beckmeyer's MTC-SHell, and when I try and run sozobon C from it, I get laughed at. This goes for any of the sozobon development tools. I can't complain too much though, I haven't called Beckmeyer tools to find out if they have a solution to this yet. Rex. -- Rex Jolliff (rex@otto.lvsun.com, {convex, texsun, mirror}!otto!rex) The Sun Newspaper - |Disclaimer: The opinions and comments in Nevada's Largest Daily Morning | this article are my own and in no way Newspaper | reflect the opinions of my employers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Why are we letting the government drug propaganda get the best of us?
leo@philmds.UUCP (Leo de Wit) (08/31/89)
In article <123950@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: [] |Why can't someone just pipe up and say "I'm using a _window system based_ ^^^^ Funny you use the word 'pipe'; it is also relevant to this discussion in a way you probably didn't suspect. |multitasking OS right now, and I a) don't like it, or b) am not using it |as one nor do I ever use it as one." | |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 ... Depends on how well designed the multitasking and the rest of the O.S. were; for instance, I wouldn't call a csh in a BSD environment 'not flexible enough'. And my experience is that a good windowing system should be used on a large screen (to add another point to the discussion). | ... and there has to be other programs that _know_ your |OS is multitasking so that they can take advantage of it if they choose |to. No. It is nice to have multitasking on the program level, but it is not inherently necessary to be useful. A good example is the pipe concept in UNIX (there it is 8-): two processes communicating through a pipe don't have to know they read from/write to a pipe, yet the O.S. decides for them whose turn it is. The multitasking is, so to speak, transparantly for the application (of course there has to be some means to set up the pipes and the processes, e.g. by a shell). | These two requirements eliminate every single "micro" (except the |Amiga) from the test. Hm, Amiga owner 8-) ? [] |Lets see if we can find those silent individuals who can present the |opposing cases. These would be the Amiga user who is saying : | "This multitasking stinks, every time I turn around it has | made my life miserable." | |and the ST/Mac/PC user who is saying : | "You know, if only I had a multitasking OS, this is what | I could accomplish." Compiles in the background, a file being printed, while reading netnews ... Wow! Leo.
exspes@gdr.bath.ac.uk (P E Smee) (08/31/89)
In article <16658@pasteur.Berkeley.EDU> landay@cory.Berkeley.EDU.UUCP (James A. Landay) writes: > >I am an Atari ST user. I would love to have a multitasking OS, because I >KNOW what kind of stuff I can do with it (from using Unix, X, Suns, etc.) > Fair comment. If you would find it useful, I'd love for you to have it, as well. >Anyone who says otherwise must not have had much experience with >multitasking OSs. > Unfair comment. (We gonna have this argument *again*?) I've been using multitasking OSs since 1963. I've written several multi-tasking special-purpose systems, and worked *on* one MT general purpose O/S and *with* probably two dozen different ones. I *know* what multitasking can do for you (so Please don't send me e-mail explaining it). I also know what it can do *to* you, and how much overhead it imposes on the system. *I* do not want a multitasking OS for *my* micro, because it would be of zero use, and measurable inconvenience, for what *I* use *my* micro for. I *would* like an multitasking OS for the ST to be available, because I would like people who could make use of it to do so, and because it would broaden the potential market. But I would like to be an option, or to be turn-off-able, so that *I* didn't have to put up with it. (On the flip side, I would *not* want to have to do my *work* computing without multitasking. For what I do at work, MT is not only useful, it's virtually essential.) Read this paragraph again. I do need MT when it is appropriate for what I do. The *'s are to emphasize the following situation: There is a reason that I don't want MT on my ST. It is not that I don't understand or appreciate MT. Rather it is that I do understand it, I know what it is good for. And, I know what I use my ST for. That use would be hindered, not helped, by a multi-tasking system. I'm hoping that the *'s will save me from patronising 'educational' mail. This is *my* opinion, based on *my* knowledge of *my* needs. Your mileage will certainly vary. But keep in mind that 'lack of understanding' is not the only reason for not wanting something. My needs may change in future. If so, I'll get a multitasking home machine. For now, no thanks. My main point (one of my favourites) is that there is NO perfect machine, no perfect type of OS, no perfect language, ... The trick is to recognise when any particular thing is appropriate, and when it is simply a gimmick. That is NOT a characteristic of the thing alone, but depends strongly on the context in which the thing is going to be used. -- Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes
david@bdt.UUCP (David Beckemeyer) (08/31/89)
In article <426@h.cs.wvu.wvnet.edu> jlf@a.cs.wvu.wvnet.edu (Jack L Forester) writes: >I have been using the Beckmeyer MT C-shell for better than three years now. >I have had my share of problems with it, but overall, I like it and I *use* >it. (BTW if anyone knows where I can get info on upgrades, please let me >know). > [ I'm following up to this on the net because I've recently got a lot of requests for info about upgrades. I'll be brief. ] Beckemeyer Development Tools runs a 24hr. BBS where we post upgrade information. The BBS has general interest message bases and files for downloading (free access to anybody) and it has several private message bases and file download areas for registered owners of products. This has become the primary source for upgrade information. New versions of BDT software are often posted to the BBS for downloading by registered users. The BBS also has many "freebie" utilities and doc files specifically designed for our products (e.g. MT C-Shell) and many files that are generic. The BBS also allows users to read comp.sys.atari.st (it's exported to a BBS message base) and it has a UUCP/Internet E-Mail Gateway. Since it's in 415, it's reachable via PC Pursuit. You don't have to be a BDT product owner to use our BBS - it's free to anybody. The BBS number is (415) 452-4792, 1200 or 2400 baud, 24hrs. After you connect, press a RETURN until you get a "login:" prompt, then type 'bbs' (all lower case), press RETURN and follow the BBS prompts. -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." 478 Santa Clara Ave. Oakland, CA 94610 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |
mboen@nixpbe.UUCP (Martin Boening) (09/01/89)
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. 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. 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. Just thought I'd add this to heat up the discussion. Martin -- Email: in the USA -> ...!uunet!philabs!linus!nixbur!mboening.pad outside USA -> {...!mcvax}!unido!nixpbe!mboening.pad Paper Mail: Martin Boening, Nixdorf Computer AG, DS-CC22, Pontanusstr. 55, 4790 Paderborn, W.-Germany
david@bdt.UUCP (David Beckemeyer) (09/02/89)
In article <1081@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <123950@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >|and the ST/Mac/PC user who is saying : >| "You know, if only I had a multitasking OS, this is what >| I could accomplish." > >Compiles in the background, a file being printed, while reading netnews ... >Wow! > > Leo. OK, I do all the above on a Mega ST-4 with MT C-Shell, Mark Williams C, the MT C-Shell print spooler, and the Bootstrap News software with MT C-Shell UUCP. Using the visual shell (VSH), I can even do it with GEM windows. Admitedly, using VSH is slower and on the rather small ST screen, it isn't as nice as a 19" monitor. But it's handy to be able to have, for instance, a kermit login session to a Unix box in one window, with a local compile shell in another, and another local (inactive) shell in case I want to type another command (e.g. to check out a local file). It all works. It's not a Cray, but you can do it, today, with software and hardware that exists and that you can really buy for an Atari ST. A plug you say? Well maybe - but it's also true. Another example of real multitasking on the ST is the custom systems that we have developed based on the RTX kernel. Here's an internal layout of a 4 user custom Point-of-Sale/Accounting system installed at a Art Supply. It has two touch screen POS 1040 ST computers, with bar code readers, and receipt printers. It has a Wyse-60 terminal used for receiving merchandise into inventory and bar code ticketing. It is all run from a 1040 ST with a BMS drive. Each touch screen 1040 system runs RTX with the following processes. The connecting lines show interprocess communications. Application (draw graphics, interact with user) ^ ^ | | | v | Network Protocol <-> Host Server (special ops) | ^ v | Multplexer <---------+ Driver ^ | RS-232 port v Multiplexer (Hardware) | | | | | | | +- Touch screen I/O | | +---- Network (Host) | +------- Printer +---------- Bar Code Reader The main 1040 also runs RTX and has the following cooperating processes: POS/Accounting Application POS/Accounting Application System Console Wyse 60 Terminal ^ ^ ^ | | | +----------+ +----------------+ | | | | v v | DataBase <---> (Hard Disk Databases) | Server | ^ ^ | | | | Touch Screen <-----+ +------> Touch Screen | Server Server | ^ ^ | | | | v v | Network Protocol Network Protocol | ^ ^ | | | | | | | Multplexer --------------------------+ | Driver ------------------------------------------+ ^ | RS-232 port v Multiplexer (Hardware) | | | | | | | +- Network I/O to Touch screen #1 | | +---- Network I/O to Touch screen #2 | +------- Bar Code Printer +---------- Wyse 60 terminal Actually there are even more tasks than show in the pictures because some functions of the main applications are actully spawned off into a sub-task, as needed. The database server uses the client/server model using RTX message queues to communicate. The touch screen systems communicate with the Host 1040 using RS-232 with a error correcting packet protocol. The network protocol runs independently and asychronously from he rest of the system (i.e. a packet could come in at any time). The above described system has been running for almost three years. I used it as an example because it is uses 100% Atari ST computers (3 1040s) and all the CPUs are running RTX in real-time, commuicating 24 hrs. a day 365 days a year. So now somebody tell me there isn't any usable multitasking for the ST. -- David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have Beckemeyer Development Tools | a breath mint." 478 Santa Clara Ave. Oakland, CA 94610 | Bart - "The Simpsons" UUCP: {uunet,ucbvax}!unisoft!bdt!david |
mitchell@cbmvax.UUCP (Fred Mitchell - QA) (09/03/89)
In article <16662@pasteur.Berkeley.EDU> jlemon@cory.Berkeley.EDU.UUCP (Jonathan Lemon) writes: >} >}Anyone who says otherwise must not have had much experience with >}multitasking OSs. > >Me too. I would really like multi-tasking on my mega! In the end, I had >to decide that the other little advantages of the Mega outweighted the >multi-tasking of the Amiga. (at least for my case) >-- >Jonathan ...ucbvax!cory!jlemon jlemon@cory.Berkeley.EDU What were these advantages, if you don't mind me asking? Thanks. -- |*******************************************| -Compliments of /// |* All thoughts and comments are soley *| Fred Mitchell \\\/// |* thoses of The Author and has nothing to *| \XX/ |* do with Commodore-Amiga. *| Software QA - Commodore-Amiga |*******************************************|
jdutka@wpi.wpi.edu (John Dutka) (09/03/89)
>What were these advantages, if you don't mind me asking? Thanks. I think I'll stand back a little and wait for this reply. . . +-------------------+--------------------------------------------------------+ | John A. Dutka | "No matter how big a straw, you can't suck water up | | WPI Box 2308 | more than 34 feet." | | 100 Institute Rd. | -A PROFESSOR WHO WISHES TO REMAIN ANONYMOUS. | | (508)755-7128 +------+--------------------+----------------------------+ | Worcester, MA 01609-2280 | jdutka@wpi.bitnet | jdutka@wpi.wpi.edu | +--------------------------+--------------------+----------------------------+
jlemon@cory.Berkeley.EDU (Jonathan Lemon) (09/05/89)
In article <7816@cbmvax.UUCP> mitchell@cbmvax.UUCP (Fred Mitchell - QA) writes: >In article <16662@pasteur.Berkeley.EDU> jlemon@cory.Berkeley.EDU.UUCP (Jonathan Lemon) writes: >> >>Me too. I would really like multi-tasking on my mega! In the end, I had >>to decide that the other little advantages of the Mega outweighed the >>multi-tasking of the Amiga. (at least for my case) > >What were these advantages, if you don't mind me asking? Thanks. Well, this is my _personal_ opinion, not intended to start a war or anything, of course... 1. I wanted to be able to run MAC software (for my fiancee). A-MAX (?) was not available for the Amiga. 2. I liked the extremely sharp display of the 70hz monochrome monitor, as I do a lot of telecomm/programming. Amiga had more colors, and could use both composite and RGB monitors, but upon closer inspection, I decided that their high-resolution (interlace) mode was unusable without a FlickerFixer, which cost money I didn't have at that time. 3. I wanted a more "graphical" computer - to get away from the MS-DOS world. With the Amiga you had to put up with the CLI, mount/remount commands, etc, and ad nauseum. While there are graphical shells for the Amy, just as there are CLI's for the Atari, I didn't want that as my "native" mode. 4. I read both comp.sys.amiga and comp.sys.atari.st for about 6 months before deciding. During that time, I picked up a lot of "patches" for both computers, and also heard a lot about the Amiga guruing. From this, as well as listening to friends who owned Amigas, I gained an impression that sometimes the machine is not as stable as people would like it to be. Now, this may or may not be true, but it made a negative impression on me. 5. Finally, there was the issue of price. I did not like either the A500 nor the 520/1040 ST, soley on the basis of the way they looked/felt, and both had this mass of wiring coming from the back. (I like the keyboard in my lap sometimes!) Being a college student, I was a little short on money. Given all the above reasons and other little nits (appearance, MIDI, DMA, both run IBM, etc..) and the fact that I could get (did get) a Mega 2 mono system for only $1100, compared to the fact that a Amiga 2000 cost roughly $2000, I chose the best computer for me and my budget. Now, make what you will of the above. (if you haven't hit 'n'.. :-) ) I would say that both of the computers are roughly equivalent, but the ~$800 more that I would have had to pay for the Amiga was not worth the multitasking that I would have gotten. It would be nice, but not necessary. (and I use multitasking all day at work/school where is _IS_ necessary (Suns, HP 9000's) but at home, it would just be _required_ occasionally) -- Jonathan ...ucbvax!cory!jlemon or jlemon@cory.Berkeley.EDU
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/14/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."