HDTenEightyP/NetNews huggingface dataset:
From: straka@cbnewsc.cb.att.com (richard.j.straka)
Subject: Re: IBM SUCKS! !(.NOT.)
Organization: AT&T
Distribution: na
Date: Wed, 30 Sep 1992 04:51:11 GMT

In article <dx_p-8f.marquis@netcom.com> marquis@netcom.com (Roger Marquis) writes:
>In article <6056.2ac6d891@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>>>>In article <1657@anagld.analytics.com>, sammy@anagld.analytics.com (Sam Blackburn) writes:
>>>>> Macs aren't suited for a lot of applications that PCs do today.  
>>>>Name *ONE*.
>>> Anything that requires system programming (batch files).  
>>I have get to see a "system programming" application. This is a bad answer.
>>That's unfortunate. You're other answers were quite good.
>
>OK, tell me how to do the following on a Mac then.
>
>->We'll, I just finsihed a 150 line batch file that collects timesheet
>->data from 5 remote offices of a large law firm and uploads them to
>->their HP3000 for processing on a nightly basis.  I would have rather
>->have used a UNIX shell script to do this but the ability is there in DOS.

I thought that A/UX could handle standard shell commands. :-) Of course, it
can.

>->I don't see an equivalent ability in the MacOS.  Perhaps when Frontier

True, the Mac OS does not do this very well currently.  But A/UX should do
this just fine.

I don't see why running A/UX on a Mac (really, running the Mac OS on top of
A/UX) is any stranger than running Windows on top of DOS.  Let's get real
here!

>->is bundeled with the OS ... we'll see.>
>
>
> DOS batch commands were clearly useful here to 1) compare
>files for validity, 2) verify the existence of a file, call another
>batch file to modify the timesheet data (which could not have been
>done without a command line), 3) set and check that the specified
>drives were mapped, 5) write the output to a log file for verification
>verification, 6) maintain the previous 2 days log files for reference,
>etc.  I'm sure there's more but this is a clear case of an everyday
>business problem that was easily handled by a PC.  It's questionable
>whether the same thing could be done on a Mac with or without Frontier.

I think most would agree with me when I propose that DOS presents all of the
cryptic, arcane command syntax inherent with UNIX, but provides little of
UNIX's power or elegance.

And then, there's my neighbor who just bought a new PC clone and couldn't
figure out how to format a disk.  Let's see, the manual says (amongst a
dozen or two permutations): format a: /f=720k (or whatever).  I was the
only one out of 3 in the room who could figure it out (the other was a IBM
mainframe-type consultant).

If I've got to type something as arcane as
	find ./* -depth -print |cpio -oc >~/archive.cpio
	(actually a pretty trivial example),
at least the UNIX shell commands really are  a *lot* powerful than DOS'.
-- 
Richard Straka      AT&T Bell Laboratories
UUCP:     att!ihlpw!straka       INTERNET: richard.straka@att.com
From the 'ed' manual page: "A one-character regular expression is a regular
expression that matches whatever the one-character regular expression matches."
From: patb@mcl.ucsb.edu (Pat Breitenbach)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: IBM Funny
Date: 4 Oct 92 22:23:53 GMT
Article-I.D.: mcl.patb.718237433

In <TOMSTER.92Oct1144544@bigwpi.WPI.EDU> tomster@bigwpi.WPI.EDU (Thomas Richard Dibble) writes:

>Quick!  what do the left and middle buttons do on the Mac?!?   ... :->

My mouse only has one button.

>   Nope. The menu bar stays up at the top of the screen where you can get to it
>   accurately (even in the face of Fitt's law) because vertical overshoot is
>   absorbed by reaching the top of the screen.

>I'd have to agree here.  One of the worst experiences I've had in Windows
>is trying to pull down a menu but instead grabbing the title bar of the
>app and dragging *it* down the screen.  The better point of this is that
>the menu bar is more closely associated with the application than if it were
>at the top of the screen.

This is/was true when computing was/is more application oriented, but it
seems that trends are to more documented oriented computing. On top
of the vertical bound, I think the Mac's menu bar is better by far.

>This really has little to do with the discussion, but (in the hopes of this
>becomming a bash-MS newsgroup) about the saddest quote I ever read was
>(I forget who said it) "I know, Turbo-C is far superior to Microsoft C,
>but I use the MS product because it is industry standard."  Truly pitiful
>that 'industry standards' are valued more highly than innovation and
>efficiency, IMO.

This is ridiculous. This might be true of you were locked up in a room.
The advantages of using standards go far, far beyond merely using
a piece of software and are too numerous to list. On the contrary,
it seems people don't like to use MS products just because they
do own much marketshare. I can't think of much that is less productive
than having a bunch of different word processors in the same office.
People that bring non-Word files to our lab to print are SOL. I tell 
them to get with it.

>   -- 
>   Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958

>		---- tomster@wpi.wpi.edu
>--

Pat Breitenbach		patb@mcl.ucsb.edu
From: ewright@convex.com (Edward V. Wright)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: IBM SUCKS!
Date: 29 Sep 92 16:57:12 GMT
Article-I.D.: convex.ewright.717785832
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In <6064.2ac71886@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:

>> Non-critical embedded applications: point of sale units, for example 

>There are Macintosh versions of these units.

Didn't one of the major Japanese electronics companies license
the right to use the Macintosh interface in future high-resolution
digital television sets?

I wonder if PC advocates will demand a command-line-based version?
I can see it now: 

 > play -chan 3 -snd stereo -vol 4 -res 5 -vcr rec -tim 60 "Star Trek"

:-)
From: fischer@iesd.auc.dk (Lars Peter Fischer)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: IBM SUCKS!
Date: 6 Oct 92 03:11:52 GMT
	<1657@anagld.analytics.com> <6051.2ac3aa51@hayes.com>
	<TOMSTER.92Sep28200453@bigwpi.WPI.EDU>
	<CKD.92Oct4021357@loiosh.eff.org>
Organization: Mathematics and Computer Science, Aalborg University


If IBM sucks, how come Apple is going to use their chips and is
developing their new OS with 'em? Does this mean that 3 years from
now, "Apple suck" will be true?

/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin
Newsgroups: comp.sys.mac.advocacy
From: hees@cubic.com (Phil Hees)
Subject: Re: Why Macs are better (and the others aren't)
Organization: Cubic Toll Systems
Date: Mon, 05 Oct 92 23:00:12 GMT

In article <1992Oct03.225356.19770@NeoSoft.com> peter@NeoSoft.com (Peter da Silva) writes:
>In article <ibhan.718038875@husc8> ibhan@husc8.harvard.edu (Ishir Bhan) writes:
>> peter@NeoSoft.com (Peter da Silva) writes:
>> >In article <qdkzdx#@rpi.edu> johnsd2@rpi.edu writes:
>> >> This conversion, incidentally, is only done when the app is switched
>> >> into the background.
>
>> >Why is there such a thing as the "background"?
>
>> Because humans are usually only able to deal with one application at a time.
>
>People are usually able to deal with one *activity* at a time, but saying
>they can only deal with one application at a time is like saying they
>can only deal with one utensil at a time.
>
>Right now I'm watching a program convert some sagans of lines of PL/M
>to C in two windows (one logging the include files, the other error messages)
>while editing the source of the translator in one window and compiling in
>another. Earlier I was running a font editor, an application using the
>custom font I was editing, and the same compiler and editor windows.
>
>Each of these needs as much of the CPU as they have use for, and I sure
>don't want the converter thrown into the "background" because I pulled
>up the editor... or the mail or news programs.

I'm afraid I'm losing track of who is advocating which system here, and
perhaps I'm not the only one.  Just to make it clear, under System 7 on
the Mac, applications running in the background are still in fact running.
For example, I can be FTPing, calculating Mandlebrot functions, etc. in
the background while running an editor in the foreground.

--
Phil Hees
hees@cubic.com
Newsgroups: comp.sys.mac.advocacy
From: derek@cgrg.ohio-state.edu (Dariusz Bolski)
Subject: Re: CLI vs. GUI RIDICULOUSNESS!!!!Read/New/Followup
Organization: OSU Advanced Computing Center for the Arts and Design
Date: Sat, 3 Oct 1992 05:11:15 GMT

In article <strobl.717873156@gmd.de> strobl@gmd.de (Wolfgang Strobl) writes:
>I would like to add yet another advantage specific to CLIs, which
>I haven't seen discussed here.
>
>CLIs not only allow you to see where you are, but how you got
>there, in addition. You see a trace of your commands and what 
>the systems reaction was. I don't know any GUIs which offer 
>a similar capability. If you change something, it's changed,
>as if it had always been so. The display of the actual state
>of the system is great - this compensates for much of the
>above problem, but the display of the state change is lousy,
>at best.
>

Excellent point. I often save my history to a file documenting
how did I obtain the result. Most useful in the future attempts
to recreate the process (and result).

>Wolfgang Strobl

Dariusz Bolski
-- 
Dariusz Bolski     Ohio Supercomputer Center, IBM POWER Visualization System
Systems Programmer Ohio State University , Columbus U.S.
                   The Advanced Computing Center For The Arts And Design
e-mail: derek@cgrg.ohio-state.edu  derek@osc.edu
Newsgroups: comp.sys.mac.advocacy
From: johnsd2@vccsouth07.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: IBM Funny
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Mon, 5 Oct 1992 17:19:51 GMT

In article <1992Oct05.033951.27090@NeoSoft.com>, peter@NeoSoft.com (Peter da Silva) writes:
|> In article <fbqzydg@rpi.edu> johnsd2@rpi.edu writes:
|> > Why? C'mon, don't just assert. We're Macheads, we won't believe you! :)
|> 
|> How many times do I have to list the same points?
|> 

I dont know what points you think are relevant to this.
Just mention them, at least.

[deletia- windows GUI on a Mac would be good, allegedly]
|> 
|> Current Macs. Say, an SE/30. That's the last modern Mac I spent much time
|> with, and it was pretty painful to set things up the way my client wanted.

How was that? And how would Windows or the Windows GUI have made
it easier?

|> > |> > Furthermore, it isn't a standard shortcut for Windows.
|> 
|> > |> If it was a menu item in any application, it would have a shortcut
|> > |> automatically.
|> 
|> > Yeah, but its not STANDARD. Why should you care?
|> 
|> Because *I* might be using it all the time.

Common commands like that should have keyboard equivalents
for you, then, even if they aren't standard ones.

|> > because if the same
|> > command has DIFFERENT shortcuts in different apps, you will get
|> > them confused. (or I will, at least. I do.)
|> 
|> Not, you won't. Because the shortcut is always sitting there in front of
|> you.

Is not. Its hidden up there in a menu. :)

|> > |> That's because you're looking at too much of the system (applications, for
|> > |> example, and design guidelines) and calling them part of the GUI.
|> 
|> > Unless you are just takling theory, you can't separate them.
|> 
|> I am. I don't like Microsoft, and I certainly wouldn't recommend Windows
|> to anyone except as a joke, or as an alternative to DOS 5 shell.

:) Well, a few posts back you DENIED you were talking theory only,
so I assumed you weren't but if you are, by all means lets do so.

Go ahead and pull out these elements of windows that will make
such a difference.
-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Newsgroups: comp.sys.mac.advocacy
From: deek@brahms.udel.edu (Michael J Deerkoski)
Subject: Re: 7.1 vs. OS/2 and Windows NT
Reply-To: deek@brahms.udel.edu (Michael J Deerkoski)
Organization: University of Delaware - Apple Student Rep.
Date: Sun, 4 Oct 1992 05:23:39 GMT

In article <1992Oct03.230439.19989@NeoSoft.com>, peter@NeoSoft.com (Peter da 
Silva) writes:
> Funny how all these things that I've been doing for years don't become
> necessities until Microsoft offers them. I judge necessity by what I want
> to do, not what sells

EXACTLY.  Look at Microsoft's latest "innovations":  Windows 3.1 (TrueType!  
wow!), WFW workstations (Filesharing without a server!  Wow!), Microsoft 
Multimedia for Windows (Multimedia on existing platforms...with a special 
sound board, and special video recording equipment, and...wow!)

Microsoft makes a living trumpeting others innovations.

Michael Deerkoski           |Internet: deek@brahms.udel.edu
Undergraduate               |          deek@freezer.cns.udel.edu
University of Delaware      |CompuServe: 76300,2612|AppleLink:      deek
Apple Computer Student Rep. |ARA:      302 837-6473|America Online: deek
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Why Macs are better (and the others aren't) (long)
Date: 1 Oct 92 16:28:20 EDT
Followup-To: md.de>

Organization: Hayes Microcomputer Products, Norcross, GA

In article <strobl.717876881@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
> 
> Well, you have the choice between a 2.88MB and a 20.8 MB floppy. Which 
> do you prefer? 

3.5" 128MB Magneto-Optical disk.

<big grin>

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
From: johnsd2@rs6212.ecs.rpi.edu (Daniel Norman Johnson)
Subject: Re: When is a CLI faster than a GUI?
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Thu, 1 Oct 1992 06:44:13 GMT

In article <1992Sep30.235029.3723@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
|> In article <3tjzqnk@rpi.edu> johnsd2@rpi.edu writes:
|> >Oh good. :)
|> >
|> >|> Command history                        (mouse macros don't count)
|> >
|> >A workaround to a problem GUIs dont (well, shouldn't) have,
|> >namely long obnoxious commands. GUIs have _short_, obnoxious
|> >commands. :) All the difference in the world.
|> Aha! Found a week spot there apparently. Histories are maybe my favorite
|> reason to use a CLI. If you run several different programs sequentially,
|> and repeatedly (as I always seem to do) it's a great timesaver,

So why don't mouse macros count for this?

Incidentally, care to get more specific about what you are doing?
It sounds very much like a script would do wonders at reducing your
keystroke count (for what thats worth); It may be that theres some
really great GUI way to do it, too. (Unless you correct me, Ill
probably assume so. Just to be difficult)

|> >|> Command name completion (not filename) (possible, but not implemented)
|> Actually coming to think of it, since a GUI doesn't have a concept of
|> a PATH, where the commands reside, the only option you have is fill up
|> the main screen with icons as 'immediately available' commands. Obviously
|> this is rather limiting, and as soon as you move a window over it you
|> are losing time, uncovering parts of yor desktop.

Not so. You can also put them in your apple menu.

Its also worth mentioning that Macs generally do NOT have
as many little tools on the desktop as PCs have little programs
on the path. That's because a lot of these functions are
implemented with Extensions. They appear as menus in the finder,
or weirder things (command, options, shift, control, capslock click
in a window zoom box and a menu comes up... :)

Obvious example that comes to mind: A program that adds a menu
next to your balloon help menu which can change screen depth.
I could probably come up with a few more, if ya care. But I think
you see what I mean now.
-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
From: jess@gn.ecn.purdue.edu (Jess M Holle)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: How many "Macs" do you see doing important work?
Date: 28 Sep 92 23:35:31 GMT
Organization: Purdue University Engineering Computer Network

In article <ft_pf=b.nagle@netcom.com> nagle@netcom.com (John Nagle) writes:
>chris@lynx.msc.cornell.edu.UUCP (Chris Manly,,,2577951) writes:
>        You don't see that much engineering work done on the Mac, either.
>The PC board design programs for the Mac are inferior to the ones for
>Intel-based machines.  CAD on the Mac has never really taken off, although
>CAD ought to be a great Mac application.  Vendors who have products on both 
>platforms report that the Mac versions just don't sell.

MacBravo does have a very substantial PC board design module.  I assume
from the quality of the rest of Schlumberger's products that this is not
"inferior."  If it is, then how?  Also, though there are not as many 
players in CAD on the Mac, most of the big ones are represented: AutoCAD,
VersaCAD, MacBravo, Intergraph (Microstation), Vellum, Generi CAD, etc.
One BEAUTIFUL built in capability in a Mac is the ability to use multiple
screens with different windows/views on each screen.  You can't BUY this
for the PC.

>        Part of the problem is that, in CAD and engineering work, sheer
>speed, especially floating point speed, matters.  Macs have traditionally
>had less price/performance, and floating point coprocessors are not all
>that common in the Mac world.  SANE, Apple's numerics library, is
>painfully slow, even with a coprocessor present.  (There's a big
>performance degradation, perhaps 10x, from using SANE vs compiling floating
>point instructions for a coprocessor).

Floating point coprocessors are quite common in the Mac world.  Lower end
machines are sold without them, but they can be added on later.  SANE is
slow, but more accurate than anything that I am aware of on the PC.  All
serious engineering software for the Mac calls the FPU directly, thereby
eliminating this bottleneck.

The PC is cheap, but that is ALL that it has going for it.  Any serious
CAD work on a PC requires memory hacks to get around DOS's 640K limit.

Jess Holle
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: IBM SUCKS!
Date: 28 Sep 92 14:36:54 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Sep27.122822.22820@NeoSoft.com>, peter@NeoSoft.com (Peter da Silva) writes:
> In article <6051.2ac3aa51@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>> > Macs aren't suited for a lot of applications that PCs do today.  
> 
>> Name *ONE*.
> 
> Non-critical embedded applications: point of sale units, for example 

There are Macintosh versions of these units.

> bulletin board systems. 

As for these.

> In both cases the user interface is irrelevant (you can't use a
> mouse at a terminal, and a bitmapped display over a modem is problematic)
> and price is the overriding concern.

I submit that user interfaces are just as important on BBSs and point of
sale terminals as anywhere else.

There are graphic BBSes in place now. TeleFinder appears to do an excellent
job, and it is just the beginning. With OCE, you're going to see a lot
more store-and-forward applications developing more quickly on the Mac.

> Multiuser applications, running UNIX. A Mac is pretty much a workstation.

Yup, a Mac is a workstation, but that is what it is designed to be. OTOH,
Macs can run A/UX, and do just the same multiuser applications as your
Unix box does.

> Even with A/UX it's better suited to a desktop role than timesharing or
> a fileserver.

Acting as a file server is a good point. Of course, the MacOS has this
capability built in to every workstation. The same can't be said for
DOS or Windows, and I'm not sure of OS/2. Some versions of Unix can
share files, I think. Maybe.

The best file servers are those designed to be file servers -- Novell has
got some great technology here, for example. While the Mac doesn't make
a great file server, I wouldn't label it as "unsuited" for this application.

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Organization: Sophomore, Physics, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.mac.advocacy
Date: Sun, 27 Sep 1992 07:47:58 -0400 
From: Faisal Nameer Jawdat <fj05+@andrew.cmu.edu>
Subject: Re: When is a CLI faster than a GUI?
	<ewright.717457732@convex.convex.com>

article quoted for reference after body of my text

Most of the following is only partially true.  It works for beginning
users, while it is not true for someone who uses the software on a
day-to-day basis.  It assumes that the person remembers
commands as words, not character strings (which are rememberred
differently, and are harder to misspell, just as it is easier to get
one wrong trying to remember the number 2,684,878, than rememberring
my phone number 268-4878).  It assumes that users need to go through a
relatively long length of time to remember a command, which is true
for new users, but not experienced ones (it takes me a lot less time
to type 'ESC x bat-ins TAB' than to go to the message window, choose
select all from the menu, change to the editting window, and finally
select 'paste excerpt' from the edit menu).  It also assumes that it
is easy to pick out one icon always, whcih is not true - when you have
20 icons in a floder it can be a pain in the arse to find the right
one, and there's no command completion when you're trying to find an
icon (love that tcsh).


ewright@convex.com (Edward V. Wright) writes:
> Proof, please.  I strongly doubt that typing /fin, by itself, can
> import anything.  You have to recall the file name, the directory
> name, figure out the spelling, type the directory and file name.
> All that takes a lot of CPU power on the part of the liveware, 
> hence, a lot of time.  Researchers who've done studies have
> found the open-dialog box to be a *lot* faster, because all
> you have to do is identify the name instead of remembering it.
> I assume you have studies of your own to refute these?  
> 
> >They can. HOwever, moving a mouse to a menu and then clicking takes time.
> 
> Remembering a command takes far more time.  The human brain
> is good at recognizing things; bad at remembering them.  
> Computers are good at remembering and bad at recognizing.
> The Macintosh interface allows both human and machine to
> do what they're good at -- the human does the recognizing,
> the machine does the remembering.  CLIs reverse this --
> the human is the one who must remember, while the machine
> must recognize.
> 
> The brain, however, perceives the time differently depending
> on what it's doing.  If it's performing a low-level task,
> such as pointing or recognizing, the brain gets bored and
> perceives that the task is happening slowly.  If it's a
> high-level task, such as remembering a command line, the
> brain is so occupied that it loses track of time.  Thus,
> the CLI *seems* to take less time than choosing a menu.
> However, an external observer timing the tasks sees that
> the reverse is true.
Newsgroups: comp.sys.mac.advocacy