gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/07/89)
In article <BRUCE.89Jan6093706@blue.gwd.tek.com> bruce@blue.gwd.tek.com (Bruce Robertson) writes: >Please explain how a $2K model 630 is so much better than a $350 >Wyse-50 for someone doing, say, database entry all day. Another >example: factory floor diagnostics, which can benefit from screen >manipulation, but don't really gain anything from graphics. You're misleading yourself by concentrating on the bitmap graphics aspect of the 630. Much more relevant are the following: 1. ability to work on several tasks concurrently on the same terminal 2. ability to quickly cut-and-paste edit text, including output already on the display, and send it as though typed in 3. ability to capture a screen image into a separate local copy of the window 4. variety of fonts (especially large character sizes) 5. large display size (lots of text visible at once) The 630 has other spiffy features, but these should suffice. If you don't think your users would benefit, let one of them use a 630 for a while then see how he responds to the idea of reverting to his old Wyse 50.
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (01/07/89)
In article <9307@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >The 630 has other spiffy features, but these should suffice. If >you don't think your users would benefit, let one of them use >a 630 for a while then see how he responds to the idea of reverting >to his old Wyse 50. Doug - the Wyse-50 can do all that, except the different font sizes, with appropriate software support. Of course, our users use TVI-955's ;-), I have the only Wyse-50. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Now with 12 percent less fat than InterNet: jfh@rpp386.Dallas.TX.US | last years model ..." UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (01/08/89)
In article <9307@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <BRUCE.89Jan6093706@blue.gwd.tek.com> bruce@blue.gwd.tek.com (Bruce Robertson) writes: >>Please explain how a $2K model 630 is so much better than a $350 >>Wyse-50 for someone doing, say, database entry all day. Another >>example: factory floor diagnostics, which can benefit from screen >>manipulation, but don't really gain anything from graphics. > >You're misleading yourself by concentrating on the bitmap graphics >aspect of the 630. Much more relevant are the following: I agree. There is much more to a graphics display than just graphics. The examples given are definetly area's that can benefit from an improved user interface. One problem is the increased time and expense of developing software to incorporate new and better user interfaces. A prime example is the Macintosh. Almost any user can be doing fairly interesting and useful tasks with very limited training, but the cost of developing the programs for the Macintosh is higher due to developing the user interface. The primary advantage of the Mac interface is it's uniformity across applications, ease of use for non computer literate users and fast learning curve. It can also present data in more traditional and flexible ways (like emulating dials, buttons, etc). For the factory floor this means giving your factory worker more information in a more familiar format and less training time. For the database entry application you can have (for example) several screens that can be interacted with, again with less training involved. The bottom line is cost. The end users have and will continue to look at the bottom line. Sophisticated end users will generally look at all costs such as training and productivity improvements to counter increased capital costs for a more sophisticated system (i.e. graphics display, user friendly interface). Non-sophisticated end users will typically just look at the capital costs and go for a bare bones systems (i.e. your XXXX brand 80x24 terminal). -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/08/89)
In article <10773@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: >Doug - the Wyse-50 can do all that, except the different font >sizes, with appropriate software support. With enough software one can do almost anything.. I didn't realize the Wyse 50 had a mouse! I suppose one could use arrow and function keys as a poor man's substitute, but it wouldn't be nearly as fast and convenient. I also haven't seen a good mindowing system for dumb CRTs. (I've seen lots of windowing systems, just no good ones.) Except for multiple layers, which obviously requires software support on the part of the host, the 630 has all the features I mentioned built-in. This means they are available from the time it is taken out of the box, on any system supporting serial ASCII terminals. Besides, the question was whether "ordinary" users "needed" such features. If you can really conveniently have them on terminal X, then you can class that flavor of terminal X with the 630 for purposes of this discussion. I'm not trying to push a particular brand, just the general use of powerful tools.
albaugh@dms.UUCP (Mike Albaugh) (01/09/89)
From article <2117@van-bc.UUCP>, by sl@van-bc.UUCP (pri=-10 Stuart Lynne): > > One problem is the increased time and expense of developing software to > incorporate new and better user interfaces. A prime example is the > Macintosh. Almost any user can be doing fairly interesting and useful tasks > with very limited training, but the cost of developing the programs for the > Macintosh is higher due to developing the user interface. And re-develop it for every system release.... :-) > > The primary advantage of the Mac interface is it's uniformity across > applications, ease of use for non computer literate users and fast learning > curve. I'm typing this on a Mac, used as a terminal to a xenix system, so I have a bit to say about all this. My experience of the Mac is that simple tasks are indeed simple to do, without even looking at the manual. As soon as one strays from the sort of stuff covered in the tutorial, it kind of turns on you. I sometimes call this the "brick-wall" form of learning curve. Soon after you get up to speed, you try somthing just a little out of the ordinary and hit a brick wall (like a function that _only_ has a short-cut (no menu item) or one that is hidden three menues deep in a strange place. Of course it's in the manual, in _one_ place, under a name that no-one but the program author would think of calling it. Of course *nix users are used to this sort of thing, so they probably don't notice :-) Second comment. This system is pretty spiffy, as Mac's go. 16Mhz 68020 accelerator in an SE, with a Radius Full-Page Display. For the purpose of reading NetNews over a 1200 baud line, though, I'd rather have my old C. Itoh 101. A cheesy keyboard, 1-bit deep seriously ugly characters (yes a Mac can have scads of fonts, but 72 DPI make any of then small enough to get 80 columns seriously ugly), and the inability to keep up with _1200_ baud when re-painting seem a bit much to put up with when all I want to do is read the news. > > The bottom line is cost. The end users have and will continue to look at the > bottom line. Sophisticated end users will generally look at all costs such Unfortunately, the end user will also have to "look at" a terminal which was (often) chosen for snazzy features and buzz-words, rather than clear, legible characters and a usable keyboard. Note, I am not anti-bitmap, anti 630 (never seen one live), anti- X-windows, whatevr. what I am is anti- Bells_and_whistles_bought_with_money_that_could_have_gone_toward_legibility. _MY_ ideal terminal/workstation would be Mono-chrome 2Kx1K (min), 3-bits deep (minimum), 72Hz vertical mininum, and a serious keyboard. It would _never_ XOFF any host, even at 56Kbps, and it would survive staying powered on for 24 Hours/Day without swimming. But isn't this all a bit far afield for comp.lang.c? :-) > -- > Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532 Oh, yeah, I guess I should forstall the inevitable question, The Mac belongs to my wife, and she makes money with it, so she gets the desk in the spare bedroom, and my terminal gets the attic :-( | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
stox@ttrde.UUCP (Kenneth P. Stox) (01/11/89)
In article <9307@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > aspect of the 630. Much more relevant are the following: [deleted a wonderful list of 630 features] > The 630 has other spiffy features, but these should suffice. If First of all, thank you, Doug, for the comments on the 630, however, I believe you are missing the most important feature of all, the 630 is programmable. In other words, if you want to write applications that have a portion ( if not all ) of the user interface resident in the terminal, you can do so. In our minds, this is the most important feature, if you really want to have the 630 look like a wyse-50 ( BTW, can I get a VW engine for my BMW ? }:-> ), or virtually any other asynchronous terminal you may develope and download an emulator to the 630. So, to sum it up, if the 630 does not have a feature you desire, you would probably be able to program it to do so with little effort. BTW, the 630 is programmed in C using a development package sold separately. Well, enough of this, let's move this discussion to comp.terminals where it belongs, or if anyone has specific comments, please send them directly to me. ============================================================================ Ken Stox 630 Development Group AT&T Bell Labs att!ttrde!stox ============================================================================
debra@alice.UUCP (Paul De Bra) (01/11/89)
In article <815@ttrde.UUCP> stox@ttrde.UUCP (Kenneth P. Stox) writes: >In article <9307@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: >> aspect of the 630. Much more relevant are the following: > >[deleted a wonderful list of 630 features] > >> The 630 has other spiffy features, but these should suffice. If > >First of all, thank you, Doug, for the comments on the 630, however, >I believe you are missing the most important feature of all, the >630 is programmable. In other words, if you want to write applications >that have a portion ( if not all ) of the user interface resident >in the terminal, you can do so... Yeah, let's calculate again: a $100.000 computer can serve about 10 people running a curses (or similar) based application. For 50 people you need 5 times $100.000 of computer and 50 times $300 of terminals, or about $515.000. Now, with the application running locally in the terminal (and only talking to the host in small blocks) you can easily run the 50 users on just the one $100.000 computer. So all you need is 50 times the $2000 terminal, or total of $200.000. So especially for data entry, where the processing of the data is minimal and presenting the forms and parsing the user-input is the hard part the 630 (or old 5620 for that matter) is a real win. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
domo@riddle.UUCP (Dominic Dunlop) (01/11/89)
[Goodness knows where follow-ups should be posted. My guess is above.] In article <590@dms.UUCP> albaugh@dms.UUCP (Mike Albaugh) writes: >From article <2117@van-bc.UUCP>, by sl@van-bc.UUCP (Stuart Lynne): >> ... the cost of developing the programs for the >> Macintosh is higher due to developing the user interface. > And re-develop it for every system release.... :-) >> >> The primary advantage of the Mac interface is it's uniformity across >> applications, ease of use for non computer literate users and fast learning >> curve. >... Soon after you get up to speed, you try somthing just a little out of >the ordinary and hit a brick wall (like a function that _only_ has a short-cut >(no menu item) or one that is hidden three menues deep in a strange place. What developers are supposed to do is RTFM. I've got 200 pounds (UK retail, not weight) of _Inside Macintosh_, _User Interface Guidelines_ and more sitting on my bookshelf and looking rather prettier than (say) the SVID, but have I read them? Have I hell! The volume of the tracts one is supposed to read and inwardly digest in order to become a true Mac accolyte is just too great for me, and, I suspect, for most others -- including those who get to develop Macintosh applications. However, I do know that _User Interface Guidelines_ specifically counsels against short-cut-only options, and against menus nested more deeply than two layers. I'd also give Apple high marks for authoring their own religious materials from day one. Wouldn't it have been nice if Microsoft had given pointers to the features of OS/2 when MS-DOS first appeared? Wouldn't it have been nice if future VGA compatibility had been discussed when the EGA came out? _Inside Macintosh_ has always given ``dos and don'ts'' regarding the writing of applications able to grow with the Mac -- although there have been some surprises along the way, meaning that even the most conscientious developer is likely to get bitten once in a while. And besides, if your competitor brings out a spiffy new release using every feature in the latest 256k ROM (or whatever), you'd better do the same. But, the less conscientious the developer, the more often bitten. When Apple itself is shipping Hypercard, a product unable to do much with large screens, and ignorant of colour and grey-scales (although it is clever with half-tones), one begins to suspect that the problem may be widespread... -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
tanner@cdis-1.uucp (Dr. T. Andrews) (01/11/89)
In article <815@ttrde.UUCP>, stox@ttrde.UUCP (Kenneth P. Stox) writes: ) In article <9307@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: ) [deleted a wonderful list of 630 features] ... ) 630 is programmable. What this means, in short, is that you can write a program to have this terminal send anything you want. Send the proper escape sequence to it when someone is su "root", and you've just programmed it to send commands to allow unpassworded root access. Those especially concerned with security (eg: military types) may want to avoid these terminals for this reason. (Perhaps they can find someone to mark up model 33's by 1000% or so? :-) -- ...!bikini.cis.ufl.edu!ki4pv!cdis-1!tanner ...!bpa!cdin-1!cdis-1!tanner or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!tanner
muller@sdcc7.ucsd.EDU (Keith Muller) (01/12/89)
In article <815@ttrde.UUCP>, stox@ttrde.UUCP (Kenneth P. Stox) writes: > I believe you are missing the most important feature of all, the > 630 is programmable. In other words, if you want to write applications We use 630 terminals to teach the intro graphics class here. The advantage of having a very sophisticated software development environment coupled with a low cost (versus say a sun) make the 630 an ideal match. The 630 can be quickly programmed by anyone (students) who has written C programs. Keith Muller University of California
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/12/89)
In article <7055@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: >In article <815@ttrde.UUCP>, stox@ttrde.UUCP (Kenneth P. Stox) writes: >) 630 is programmable. >What this means, in short, is that you can write a program to have >this terminal send anything you want. Send the proper escape >sequence to it when someone is su "root", and you've just programmed >it to send commands to allow unpassworded root access. The download protocol requires active cooperation on the host end, for example address relocation, so it is unlikely anyone could do more than wedge the terminal via an intruder command sequence sent to it. In layers mode, normally the multiplexed channels simply aren't accessible to any intruder.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/13/89)
In article <408@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > The difference in cost is between $ 1000 and $ 1500. When you >multiply this by the number of terminals in an office, the cost starts >to become prohibitive. This line of argumentation has been refuted already, but let's try again: Why not supply your office workers with packing crates or even cardboard boxes instead of real office furniture? Just think of the savings!
gsh7w@astsun1.acc.virginia.edu (Greg Hennessy) (01/14/89)
In article <9357@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: #In article <408@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: #> The difference in cost is between $ 1000 and $ 1500. When you #>multiply this by the number of terminals in an office, the cost starts #>to become prohibitive. # #This line of argumentation has been refuted already, but let's try #again: Why not supply your office workers with packing crates or #even cardboard boxes instead of real office furniture? Just think #of the savings! I work a lot with the the National Radio Astronomy Observatory. If I design a new image programming package for use there which used X-windows how many people could use it? About four. If I designed a new image programming package that used a tek4010, how many people could use it? About one hundred. If astronomers around the world were to use it and it needed X windows, how many could use it? A few hundred? If it needed a 4010 emulator? A few tens of thousands. You can buy five $300.00 24 by 80 glass tty's instead of one X terminal. -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w@virginia.edu UUCP: ...!uunet!virginia!gsh7w
swilson%thetone@Sun.COM (Scott Wilson) (01/14/89)
In article <9357@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <408@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >> The difference in cost is between $ 1000 and $ 1500. When you >>multiply this by the number of terminals in an office, the cost starts >>to become prohibitive. > >This line of argumentation has been refuted already, but let's try >again: Why not supply your office workers with packing crates or >even cardboard boxes instead of real office furniture? Just think >of the savings! The analogy above to furniture is, as with most analogies, bogus at best. The analogy was chosen to cross a line most would agree would be unacceptable. One could make a similar analogy saying: Why not supply your office workers with designer home furniture instead of real office furniture? This analogy would obviously be chosen to reflect the original posters opposition to unnecessary spending to obtain features unneeded. The point is that analogies are sometimes convenient for exposition but are only superficially useful in proving a point. For every analogy you can come up with to support your position someone can come up with one to refute it. Ban analogies! As far as the terminal vs. bitmap display argument goes, I think there is no absolute rule. For some people/situations one is better and for others the other is better. I'd say it all reduces to a simple decision of whether the increase in expense of the hardware outweighs the increased productivity. For example, consider a receptionist that mainly answers the phone and on occaison sends a phone message by e-mail to someone. I think you could easily argue that a terminal is sufficient for this purpose and that paying more for a fancier display would not return any increase in productivity. On the other hand, people like me who make some pretense of doing useful software development are more productive given fancier displays and more powerful hardware. Here at Sun we have billions of terminals. Some of them are used by people who only occasionally access a computer. Most are used as consoles to machines (like servers) that rarely have a user sitting in front of it and therefore don't need a bitmap display. Although I've seen at lot of terminals here I don't think I've seen any in positions where I though it would be more cost effective to have a bitmap display. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA
whh@pbhya.PacBell.COM (Wilson Heydt) (01/14/89)
In article <9357@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > In article <408@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > > The difference in cost is between $ 1000 and $ 1500. When you > >multiply this by the number of terminals in an office, the cost starts > >to become prohibitive. > > This line of argumentation has been refuted already, but let's try > again: Why not supply your office workers with packing crates or > even cardboard boxes instead of real office furniture? Just think > of the savings! The argument has only been refuted under restrcited conditions--not in the general case. There seems to have been an assumption made throughout this discussion, to wit--the terminal (whether smart or dumb) is connected directly to the host with a fairly high-speed link. This is not always the case--indeed it is frequently *not* the case. Consider--with a dumb terminal, if you want a screen-full of stuff you send the request to the host which processes the request and shoots back about 2k bytes of data. Ah! Let's use a smart terminal so we have very little host processing, then all the host has to do is supply the raw data and let the *terminal* do the processing! This can work great at 9.6 kbps or faster. It's wonderful at 10 Mbps. Think about the application I work with--a typical user wants that screen of data. The source data is in about 20, 800-byte records with a side lookup to a 250-byte record for each one. (I never said it was running under unix.) Now you've got to transmit up to 21,000 bytes of data so the terminal can display 2k of them. This is a disaster at 1200 or even 2400 bps over dial-up lines. It's not too good at 9.6 kbps, either. For the price of a $2000 (or $3000, if you add the 'nice' features) terminal, you are not going to get a $500 terminal and *2* 9.6 modems and claim to be saving tons of money. Any real speed improvement will require a jump to a 56 kbps line and modems at that speed don't run over dial-up lines-- nor do they come cheap. Net result--the real world doesn't do all it's computing in the lab or in close proximity to fast connections. --Hal ========================================================================= Hal Heydt | "Hafnium plus Holmium is Analyst, Pacific*Bell | one-point-five, I think." 415-645-7708 | --Dr. Jane Robinson {att,bellcore,sun,ames,pyramid}!pacbell!pbhya!whh
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/14/89)
In article <1010@hudson.acc.virginia.edu> gsh7w@astsun1.acc.Virginia.EDU (Greg Hennessy) writes: >I work a lot with the the National Radio Astronomy Observatory. If I >design a new image programming package for use there which used >X-windows how many people could use it? About four. If I designed a >new image programming package that used a tek4010, how many people >could use it? About one hundred. We were talking about the justification for purchasing spiffy terminals rather than el-cheapo terminals. If you postulate that existing terminals must be used, that's a different question. In the context of the original discussion, those using el-cheapo terminals should get good ones in their place. (By the way, I wasn't pushing X terminals. The ones I mentioned can emulate Tektronix 4010 series as well as cursor-addressable text ttys.)
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/14/89)
In article <85237@sun.uucp> swilson@sun.UUCP (Scott Wilson) writes: >The analogy above to furniture is, as with most analogies, bogus at >best. The analogy was chosen to cross a line most would agree would >be unacceptable. Hey, if a terminal is an important part of somebody's job, then an el-cheapo model is as unacceptable as cardboard office furniture. >I'd say it all reduces to a simple decision of whether the increase >in expense of the hardware outweighs the increased productivity. Yes, that's the issue. But the "obvious" ways to evaluate it are wrong. >For example, consider a receptionist that mainly answers the phone and >on occaison sends a phone message by e-mail to someone. I can think of numerous ways a receptionist could benefit from improved computational facilities. In fact I've seen some fancy receptionist support, and it would have been severely crippled by having to use a dumb terminal. Certainly, terminals that are essentially unused need not be fancy. By the way, I was NOT pushing bitmap displays, but rather spiffy terminals. These are not necessarily related. Happens the 630 is both, but I've been careful to limit my arguments to features that do not require bitmap graphics. Others brought that up.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/14/89)
In article <22781@pbhya.PacBell.COM> whh@pbhya.PacBell.COM (Wilson Heydt) writes: >Net result--the real world doesn't do all it's >computing in the lab or in close proximity to fast connections. No, and spiffy terminals like the 630 are even MORE preferable to el-cheapo dumb terminals under such low-speed connection conditions.
bill@twwells.uucp (T. William Wells) (01/15/89)
In article <9357@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
: This line of argumentation has been refuted already, but let's try
: again: Why not supply your office workers with packing crates or
: even cardboard boxes instead of real office furniture? Just think
: of the savings!
Why not provide them with packing crates if that will do the job and
they don't mind sitting on the crates?
Not everyone needs graphics. Or windows. And if these cost more
then, for those who don't need them, the cost is not justifiable.
And may, by consuming resources that could be better spent elsewhere,
actually do damage.
For example, I have some back problems. They already cut into my
productivity; they may well cost me work time or prevent me from
working altogether. For the difference in price between the cheapest
text terminals and the cheapest graphics terminals one can buy a very
good office chair. Since money doesn't grow on trees, we must make
choices about what we buy. What would you say about the office
manager who chose to buy me a spiffy new graphics terminal instead of
a spiffy new office chair?
---
This has been a most stupid discussion: the question of what kind of
terminal is appropriate hasn't got a damn thing to do with either C
or Unix and many of the arguments that have been brought forth have
been a discredit to their proponents.
Can we go back to hearing said proponents being their usual
informative and interesting selves? Or at least move the discussion
over to some more appropriate newsgroup? Like alt.flame?
---
Bill
{ uunet!proxftl | novavax } !twwells!billkre@cs.mu.oz.au (Robert Elz) (01/15/89)
This discussion has gotten way out of hand. There's no question that bit mapped terminals (630's, X terminals, Suns, etc) are "better" than 24x80's (that is, they enable the user to be more productive). There's also no question than that they cost more. The result of this is a standard price/performance trade-off, and there is NO "right" answer that will suit everyone. However, this all started, as has been pointed out before, with questions about curses, and some comment that curses is obsolete, because the fancy new terminals are all that matters now. That's simply trash .. even given that everyone has a fancy new terminal, they're not all the same. A program written for a 630 isn't going to run on a X terminal, nor on a Sun running NeWS or SunView, nor on a ... However, a program written for curses will run on all of those. Until there's a real standard window system actually out there, and in use in a large enough number of places that you don't care that your application will only run on that subset, sane designers or portable applications will continue to use curses wherever possible, despite all its drawbacks. With that in mind, improvments to curses are still useful, and will continue to be into the forseeable future. kre
allbery@ncoast.UUCP (Brandon S. Allbery) (01/16/89)
As quoted from <590@dms.UUCP> by albaugh@dms.UUCP (Mike Albaugh): +--------------- | From article <2117@van-bc.UUCP>, by sl@van-bc.UUCP (pri=-10 Stuart Lynne): | > Macintosh. Almost any user can be doing fairly interesting and useful tasks | > with very limited training, but the cost of developing the programs for the | > Macintosh is higher due to developing the user interface. | And re-develop it for every system release.... :-) +--------------- Hey, when Microsoft can't even conform to its *own* interface definition (for DOS), you expect them to conform to an ID created by an upstart like Apple? Of *course* they didn't pay attention to any of the warnings in INSIDE MACINTOSH about features that shouldn't be used. And they've trained just about every programmer who's ever worked with DOS to be similarly ignorant of warnings. Is it any wonder that so many programs broke when System 6.0 came out? (N.B. *None* of the programs I use on my Mac broke when I upgraded to 6.0.0. I never did understand why a 6.0.2 was even needed. I guess it just goes to show that programs from programmers one can trust are better.) Sorry; flame off. +--------------- | > The primary advantage of the Mac interface is it's uniformity across | > applications, ease of use for non computer literate users and fast learning | > curve. | | so I have a bit to say about all this. My experience of the Mac is that | simple tasks are indeed simple to do, without even looking at the manual. | As soon as one strays from the sort of stuff covered in the tutorial, it kind | of turns on you. I sometimes call this the "brick-wall" form of learning +--------------- The gentle learning curve of e.g. Mac programs comes at the cost of an extremely *steep* learning curve for the programmer(s) putting together the interface. I've noticed that menus and etc. are slowly getting better as programmers become more used to the interface; and on-line help is also improving (again, slowly). Also remember that there is limited space for menu commands and the like. Even on a Mac II, if you're doing enough things at once via multiple open DAs. And I, at least, find scrolling menus to be rather annoying. +--------------- | Second comment. This system is pretty spiffy, as Mac's go. 16Mhz | 68020 accelerator in an SE, with a Radius Full-Page Display. For the purpose | of reading NetNews over a 1200 baud line, though, I'd rather have my old | C. Itoh 101. A cheesy keyboard, 1-bit deep seriously ugly characters (yes | a Mac can have scads of fonts, but 72 DPI make any of then small enough | to get 80 columns seriously ugly), and the inability to keep up with | _1200_ baud when re-painting seem a bit much to put up with when all I want | to do is read the news. +--------------- Nobody claimed that the Macintosh was the be-all and end-all of WIMP [ ;-) ] systems. (Or if they did, they're just plain wrong.) It's probably the cheapest one that works reasonably well (yes, I've used MS Windows) +--------------- | Unfortunately, the end user will also have to "look at" a terminal | which was (often) chosen for snazzy features and buzz-words, rather than | clear, legible characters and a usable keyboard. Note, I am not anti-bitmap, | anti 630 (never seen one live), anti- X-windows, whatevr. what I am is anti- | Bells_and_whistles_bought_with_money_that_could_have_gone_toward_legibility. +--------------- Which is probably why business users are buying Mac IIs, not SEs. You can get away with a larger font when you've got a larger screen to play with. And, of course, terminals like the 630 have even bigger (and higher resolution) screens which make for even better legibility. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org (soon) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
henry@utzoo.uucp (Henry Spencer) (01/16/89)
In article <7055@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: >) 630 is programmable. > >What this means, in short, is that you can write a program to have >this terminal send anything you want. Send the proper escape >sequence to it when someone is su "root", and you've just programmed >it to send commands to allow unpassworded root access. If someone else can send arbitrary bytes to your terminal without your approval, you have bigger problems than programmable terminals. Exploiting them can be fairly hard, but it *can* be done, especially if the user isn't too attentive to what's happening on his terminal. What you type is often a response to what you see. If you do "su root" and then run programs whose output you cannot trust, you again have bigger problems than programmable terminals. This time the exploitation is easy. -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bzs@Encore.COM (Barry Shein) (01/17/89)
>I work a lot with the the National Radio Astronomy Observatory. If I >design a new image programming package for use there which used >X-windows how many people could use it? About four. If I designed a >new image programming package that used a tek4010, how many people >could use it? About one hundred. If astronomers around the world were >to use it and it needed X windows, how many could use it? A few >hundred? If it needed a 4010 emulator? A few tens of thousands. They used to say this about printing terminals (or, at least, assume everyone has a paper decwriter and put the graphics to the calcomp, never assume even a dumb CRT as they were so rare.) Heck, in astronomy a very few years ago they said VMS was the only system you could consider developing software for if astronomers were to use it, it's not so true anymore and Unix is beginning to dominate all the sciences (then again, I remember when it had to be for an IBM or Cyber...) Do you still write all this astronomy code in F66? Anyhow, yes, we're on the cusp of another change...like other changes it will be too expensive/unwieldy to support two or more diverse and incompatible software environments and the old environment will lose. -Barry Shein, ||Encore|| Astronomy? Hm, I'm an aries...
bph@buengc.BU.EDU (Blair P. Houghton) (01/17/89)
In article <4684@xenna.Encore.COM> bzs@Encore.COM (Barry Shein) writes: > >>I work a lot with the the National Radio Astronomy Observatory. If I >>design a new image programming package for use there which used >>X-windows how many people could use it? About four. If I designed a >>new image programming package that used a tek4010, how many people >>could use it? About one hundred. If astronomers around the world were >>to use it and it needed X windows, how many could use it? A few >>hundred? If it needed a 4010 emulator? A few tens of thousands. > >Anyhow, yes, we're on the cusp of another change...like other changes >it will be too expensive/unwieldy to support two or more diverse and >incompatible software environments and the old environment will lose. Why compete? Compromise. I'm using X10.4 and the terminal windows can be toggled into tek4014-emulation mode. A little 'graph', a little 'plot', and my data is everyone's data. >Astronomy? Hm, I'm an aries... I'm a Camelopardis. --Blair "...with Castrovalva rising..."
consult@osiris.UUCP (Unix Consultation Mailbox ) (01/19/89)
In article <9357@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <408@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >> The difference in cost is between $ 1000 and $ 1500. When you >>multiply this by the number of terminals in an office, the cost starts >>to become prohibitive. > >This line of argumentation has been refuted already, but let's try >again: Why not supply your office workers with packing crates or >even cardboard boxes instead of real office furniture? Just think >of the savings! Why not? Because I don't sign the checks. Not that that would make any difference, I just heard this morning that we are pretty much flat broke for FY'88, which doesn't even end for five more months. (This is typical of my division at JHH, too - we even started FY'88 with extra money for a change.) It must be really nice that you can have all that modern hardware. Some of us have to deal with whatever we can get. I don't even have a "dumb ASCII" tty to use when the server for my di?kless Sun 3/50 is down, we can't spare any. The one I've got at home for dialing in is more than four years old, and well past its last legs, but can't be replaced for the same reason. Phil Kos
wcs@alice.UUCP (Bill Stewart, usually) (01/24/89)
In article <7055@cdis-1.uucp> tanner@cdis-1.uucp (Dr. T. Andrews) writes: :In article <815@ttrde.UUCP>, stox@ttrde.UUCP (Kenneth P. Stox) writes: :) [deleted a wonderful list of 630 features] ... 630 is programmable. :What this means, in short, is that you can write a program to have :this terminal send anything you want. Send the proper escape :sequence to it when someone is su "root", and you've just programmed :it to send commands to allow unpassworded root access. :Those especially concerned with security (eg: military types) may :want to avoid these terminals for this reason. There's a modified 630 that's been braindamaged specifically for military use. However, you don't need a 630 for this - a good old HP2621 or many other terminals lets you send a copy of the terminal screen to the host (for fill-in-the-form applications). About 8 years ago, there was a story in the San Francisco Chronicle about how hackers at Berkeley had broken into "the UNIX, a computer made by DEC", which was really abou this trick. It's probably less likely to bother you with a 630, assuming you run the standard terminal emulators which are owned by the system administration logins. -- # Thanks; # Bill Stewart, att!ho95c!wcs, AT&T Bell Labs Holmdel NJ 1-201-949-0705