HDTenEightyP/NetNews huggingface dataset:
From: coco@cbnewsl.cb.att.com (felix.lugo)
Subject: Re: Concerns about NeXT Prices are warranted
Organization: AT&T
Date: Wed, 18 Nov 1992 14:27:20 GMT

In article <1992Nov18.013920.29539@splunge.uucp> royce@splunge.uucp (Royce Howland) writes:
| coco@cbnewsl.cb.att.com (felix.lugo) writes:
| 
| >NeXTSTEP is great, but it's value is transitory.  Hardware investment is
| >THE primary concern involved when purchasing for a big project (and I'm not
| >talking about a one time purchase by an individual).  Software for devel.
| >purposes comes after that.
| 
| Hmm, those latter two comments may apply for you, Felix, but they don't
| apply where I come from, nor where many others come from either.  It's
| been pretty widely acknowledged for some time that initial hardware
| acquisition is not the major cost of any project of any size.  Software
| maintenance is the* single biggest cost, and by a large margin; it just
| happens to be amortized over a (hopefully) long period of time, perhaps
| longer even than the original hardware.
| 

	You're correct about the cost of software maintenance ... but, I was
not referring to the cost of purchasing hardware or software, or their
maintenance!  I was talking about how the decision to support platform X or Y
depends primarily on how the hardware will support a project and its longevity.
Software considerations, how it will help the project and its maintenance come
after the initial hardware assessment.  This may not be the correct way of
choosing, but it's the way it's currently done!  And most big projects (i.e.,
the type NeXT has had a hard time getting a notch in) operate in this manner.

| -- 
| Royce Howland, DKW Systems Corp.   |  "And since OS/2 2.0 is a 32-bit
|        Everything is IMHO          |   operating system, programs are easier
| royce@splunge.uucp  (NeXTMail OK)  |   to write and run faster, too."
| or kakwa!atlantis!splunge!royce    |  ad for OS/2 2.0

--Felix
From: ernest@pundit.cithep.caltech.edu (Ernest Prabhakar)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXTSTEP on DEC Alpha?  Rumor in Digital News & Review
Date: 19 Nov 1992 20:29:35 GMT
Organization: California Institute of Technology, Pasadena
Distribution: world
Reply-To: ernest@pundit.cithep.caltech.edu (Ernest Prabhakar)
NNTP-Posting-Host: pundit.cithep.caltech.edu

In article <BxxrIu.BK7@netnews.jhuapl.edu> chuck@nighthawk.jhuapl.edu (Chuck  
(Non-Peon) Waltrip) writes:
>...
> Another rumor is that DEC is trying to sell Alpha to, among others, NeXT.

DEC wants to sell ALPHA to everybody.  After all, they need to do something to  
survive. :-).  The way I heard it, about a year ago, is that DEC tried to  
convince NeXT to build the NRW on top of ALPHA.  NeXT looked at the price point  
and the availability date, and said 'forget it.'    It is possible DEC might be  
willing to pony up the money for an ALPHA port (the way Intel did), but I doubt  
NeXT will even start it before NS '486 is out the door, which is nearly a year  
away....

- Ernie P.

--
Ernest N. Prabhakar                  Caltech High Energy Physics
Member, League for Programming Freedom (league@prep.ai.mit.edu)
CaJUN President        NeXTMail:ernest@pundit.cithep.caltech.edu
"...and ourselves, your servants for Jesus sake." - II Cor 4:5b
#import <std/disclaimer.h>
Newsgroups: comp.sys.next.advocacy
From: gcolello@biosphere.Stanford.EDU (Greg Colello)
Subject: Re: Need For Automated Programming? (Re: I Take It Back)
Organization: DSO, Stanford University
Date: Thu, 19 Nov 92 18:55:00 GMT

In article <1992Nov19.081922.28237@cs.tu-berlin.de>  
marcel@opal.cs.tu-berlin.de (Marcel Weiher) writes:

> hlam@bnr.ca (Hayward Lam) writes:
> 
>==>If ObjecTime can produce Objective C code and can be incorporated in  
>==>IB, it would be a great design tool!! 
> 
> People stil don't get it.  The point about IB is that it doesn't  
generate
> code, it generates objects.  As you're working in IB, you're working  
with
> the same objects you'll have when your application is running.  It also
> means that nibs can act as templates and be read multiple times,  
generated
> as the app is running and read back in etc.
> 
> Marcel

Ahh..The dialog starts to heat up a little.

Actually I think Hayward got what I meant. Marcel points out what IB is,  
while Hayward points out what it isn't. It's what IB isn't that bothers  
me.

Marcel would seem to be in favor of IB as it is since that makes it most  
widely applicable (at a logical layer). Ok. I'll buy that. Then what I'm  
advocating for is a sort of IB "companion" that gets at some (or all) of  
the OC-generating needs. I guess this parallels the alread existing  
"companion" aspects of PB and IB. So am I then suggesting CodeBuilder (CB)  
now? I have a lot of specific ideas on why using IB as a springboard to a  
CB won't work, but I suspect this isn't the appropriate forum (Is that  
true? If yes, any suggestions as to where to move that kind of dialog?)

I'm not advocating for ObjecTime (or any other package), because I don't  
know yet what all it can do (or more importantly what it doesn't do). I AM  
advocating the IDEAS that code generators like ObjecTime points the way  
towards. I AM advocating some lively discussion around that subject and  
the Next.

PS. - Xanthus Craftman was mentioned to me as another example for program  
generation. It is advertised as a hypertext-like system. It is marketed  
for multi-media presentations. It lists for $1500! This points up another  
problem surrounding the autoprogramming subject. Sure packages exist,  
which when combined together produce a sort of loosely-linked  
autoprogramming environment, but you're broke and bewildered by the time  
you get there. INEXPENSIVE INTEGRATED SOLUTIONS WILL DISTINGUISH THE NeXT  
FROM ITS COMPETITORS. Expensive packages up the yazoo will not.


Greg
From: tim@Apple.COM (Tim Olson)
Newsgroups: comp.sys.next.advocacy
Subject: Re:  DEC's alpha is "way fast" according to WSJournal
Date: 21 Nov 92 21:23:25 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <1992Nov21.133955.430@tumbolia.sta.sub.org> axel@tumbolia.sta.sub.org writes:
|As this is my first posting to this group, I hope, it will come
|through ...
|
|So far, everybody in this group obviously is convinced, that the
|future lies in 64 bit-architectures. I wonder how Motorola could
|come to the conclusion that 64 bits don't improve performance
|that much (a German computer magazine said that thorough
|statistical analysis had shown that the performance increase could
|be estimated at around 1.5%) -- and the 68060 is going to be a 32-bit 
|microprocessor (in good ol' 680x0 tradition).

Going to 64 bits *doesn't* improve performance much.  In fact, it may
degrade performance significantly, depending upon how code is
generated.

There is very little existing code directly using 64-bit quantities,
so the main speedup comes from recoding library routines (such as
memcpy and strcpy) to work with wider transfer quantities.  This will
not, in general, result in a big performance improvement (the
estimated 1.5% sounds about right to me).  That is assuming that the
compilers used on the 64-bit architecture continue to only generate
32-bit code.  Once they start using the 64-bit width for standard
types (such as "long" in C), performance will drop, due mainly to the
drop in efficiency of the data cache(s).

The real reasons 64-bit microprocessors are now appearing are:

	1) The 32-bit virtual address space is becoming too small
	   for large systems.

	2) It is now fairly inexpensive to go to a 64-bit integer
	   core, both in terms of die area and speed penalty.


	-- Tim Olson
	Apple Computer, Inc. / Somerset
	(tim@apple.com)
Newsgroups: comp.sys.next.advocacy
From: shiva@vega.Stanford.EDU (Marcos Javier Polanco)
Subject: Re: Need For Automated Programming? (Re: I Take It Back)
Organization: DSO, Stanford University
Date: Thu, 19 Nov 92 19:22:56 GMT

In article <1992Nov19.185500.13990@leland.Stanford.EDU>  
gcolello@biosphere.Stanford.EDU (Greg Colello) writes:
> In article <1992Nov19.081922.28237@cs.tu-berlin.de>  
> marcel@opal.cs.tu-berlin.de (Marcel Weiher) writes:

Does anybody know what the "Wizards" are for Microsoft's Access?

From the rags out there it appears they help on the automated programming

front.

-Marcos
-shiva@vega.stanford.edu
Newsgroups: comp.sys.next.advocacy
From: fag2@cunixb.cc.columbia.edu (Farul A Ghazali)
Subject: Re: Really stupid Question: NS486 (WHEN??)
Reply-To: fag2@cunixb.cc.columbia.edu (Farul A Ghazali)
Organization: Columbia University
Date: Thu, 19 Nov 1992 13:37:14 GMT

In article <1992Nov12.165309.6902@wam.umd.edu> rsrodger@next10csc.wam.umd.edu (Robert Stephen Rodgers) writes:
>
>
>	Really dumb question.

	[stuff deleted]

>	NS486:  When?

Another question. How much will it be? 

        farul ghazali.
        columbia university in the city of new york.
Newsgroups: comp.sys.next.advocacy
From: brunkhorst@mayo.edu (Geoff Brunkhorst)
Subject: Re: NeXTSTEP on DEC Alpha?  Rumor in Digital News & Review
Reply-To: brunkhorst@mayo.edu
Organization: Mayo Foundation, Rochester MN. Campus
Date: Fri, 20 Nov 92 14:38:42 GMT

In article <1992Nov20.050828.13961@leland.Stanford.EDU>  
schemers@leland.Stanford.EDU (Roland Schemers) writes:
> Of course it will take a while for DEC to rewrite VMS so it uses a API
> interface to a micro-kernel. Their current Open VMS is basically Macro
> and Bliss code run through a translator with help from the PALcode on 
> the Alpha.

It was my understanding that DEC had VMS running on a VAX-based
micro-kernel 2 years ago (pre-alpha), as part of a A1 security implementation.
The goal of this project was to create "Virtual OS subsystems," which is a  
pretty elegant way of creating security (Large central system, but every  
security classification is maintained in a separate VM).  It was apparently  
canned due to liability reasons (DEC was not ready to take the blame for a 
security 'event' on one of these machines).

As for a VMS API for mach,  At the 1990 Fall DECUS symposium, OSF was touting
the 3.0 implementation, and how they had already created a VMS API as a test
bed API for their 3.0 work in progress.  This, along with the internal DEC  
efforts to build a 'virtual VMS' lead me to believe they have a 2 year rolling  
start for implementation of a VMS API.

NeXTSTEP API on an Alpha/OSF platform?  That would be an interesting twist... 

- Geoff
-----------------------------------------------------------------
Geoffrey Brunkhorst                           brunkhorst@Mayo.edu
Research Computing Facility, Guggenheim 10         (507) 284-1805
Mayo Foundation, Rochester MN, 55905, USA      fax (507) 284-5231
From: abell@netcom.com (Steven T. Abell)
Newsgroups: comp.sys.next.advocacy
Subject: Re: String moves/compares (was Re: 64-bit CPUs )
Date: 17 Nov 92 02:56:03 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

jfr@RedBrick.COM (Jon Rosen) writes:
>  Second question would be does guaranteeing that strings are
>  word-aligned help in 32-bit and 64-bit processors?  Do compilers
>  understand and generate good code for these situations?

This is the source of the problem. Many string operands are arbitrary
substrings of existing strings, hence, alignment of the parent strings
is immaterial.

Regarding relative costs of more complex string ops, see my recent post
where I sort of backed down due to CISC vs. RISC considerations.

Steve abell@netcom.com
From: tim@Apple.COM (Tim Olson)
Newsgroups: comp.sys.next.advocacy
Subject: Re: String moves/compares (was Re: 64-bit CPUs )
Date: 16 Nov 92 23:08:04 GMT
Organization: Apple Computer Inc. / Somerset, Austin, TX

In article <1992Nov13.225347.3138@RedBrick.COM> jfr@RedBrick.COM writes:
|>Pardon?  This is true only if you assume a brain dead strcpy
|>algorithm.  An intelligent algorithm, which always grabs an aligned
|>64-bit word, and uses masks for the beginning and ending can indeed
|>run nearly twice as fast as the same algorithm on a 32-bit machine.
|>There is no reason all the quad-words in the middle of the string
|>can't be copied as is.
|
|  I would concur with the last poster that a good algorithm should be
|  able to take advantage of the word-aligned characters.  One question
|  would be "At what point does the trade-off between doing the 
|  necessary front and back masking, and just doing the byte-by-byte
|  transfer occur?"  On the System 370, there was a similar question
|  that I once analyzed between the costs of using an MVC (move chars)
|  (which was super fast but only handled up to 256 characters) and
|  setting up an MVCL (move chars long) which handled up to 16Meg
|  character moves (and CLCL for compare chars long) but required
|  several extra registers to set up and some special handling at
|  the end.  It turned out that you could do 5 or 6 MVCs in the time
|  it took to set up and perform an MVCL on a S/370 Model 168 but 
|  when the 3033s and more powerful machines came along, MVCL would
|  win out over MVC after 2.  

I did this study for the Am29000 awhile back -- it turns out that the
break-even point for randomly-aligned strings was about 4 characters;
above that, the word-at-a-time transfer was asymptotically 4x the
byte-by-byte copy.  Of course, the 29K had the assistance of the
CPBYTE instruction and the bit-aligned EXTRACT instruction...

	Tim Olson
	Apple Computer Inc. / Somerset

Newsgroups: comp.sys.next.advocacy
From: thomsen@spf.trw.com (Mark Thomsen)
Subject: Re: Really stupid Question: NS486 (WHEN??) - Q2 '92
Organization: TRW Inc., Redondo Beach, CA
Date: Fri, 20 Nov 92 03:20:17 GMT

From the SCaN meeting last week:

	2Q93 ("June").

Reason:

	There are a lot of drivers needed for PCs.

I spoke with a NeXTie several months back and the question was "to do all those  
drivers, to get a third party to, or to wade in without them." The third option  
was already discarded - presumably by potential customers. They selected the  
first option - to get into those drivers themselves.

One of the reasons we can crank NeXT apps lots faster than PC/Windows  
developers is we write driver for PostScript and we are getting to displays and  
most printers we are likely to see. For the PC developers they have to get into  
all those drivers and adjust in their code. I expect that NeXT is hiding all of  
those drivers (in this case the printers) under the same developer's interface.  
This abstraction that people usually don't see provide huge leverage, of  
course, and will help sell NS486.

I just wish the dates had not been announced with such a major  
engineering/marketing decision left to make.

Mark R. Thomsen
Newsgroups: comp.sys.next.advocacy,comp.soft-sys.nextstep
From: andy@research.canon.oz.au (Andy Newman)
Subject: I take it all back
Organization: Canon Information Systems Research Australia
Date: Tue, 24 Nov 1992 00:28:42 GMT


The other week I was having a whinge about performance problems,
especially in the area of scrolling performance. I'm know going to eat
my hat (lucky I don't have one!) and scrape the yolk off my face :-)

Although there do seem to be (ahem) some speed degradation in NeXTSTEP
 3.0 the main problem turned out to be a pesky local hardware person
(who will remain nameless hey Graeme :-) who swapped my processor
board on me and left me with 16Mb instead of the usual 32. The second
factor seems to be related to the terminal emulators (you out there
Scott?).

So its not that bad really guys. Anyway regardless of performance (which
can get fixed, poor architecture can't) NS still remains the most
useful, integerated environment currently available.
-- 
Andy Newman (andy@research.canon.oz.au)
Newsgroups: comp.sys.next.advocacy
From: fischer@iesd.auc.dk (Lars Peter Fischer)
Subject: Re: humor(less) other newsgroup
Organization: Mathematics and Computer Science, Aalborg University
Date: 19 Nov 92 19:00:19


>>>>> "Eli" == Eli Burk (eburk@bugs.sfsu.edu)

Eli> How many ways can you love dos?

One -- with a gun against your head.

/Lars
--
Lars Fischer, fischer@iesd.auc.dk | It takes an uncommon mind to think of
CS Dept., Aalborg Univ., DENMARK. | these things.  -- Calvin
From: zeno@phylo.genetics.washington.edu (Sean Lamont)
Newsgroups: comp.sys.next.advocacy
Subject: Re: Byte Magazine pans the NeXTstation
Date: 17 Nov 92 22:41:01 GMT
Article-I.D.: u.1992Nov17.224101.3236
Organization: University of Washington, Seattle

In article <1992Nov17.215414.12562@das.harvard.edu> charuhas@virtual4.harvard.edu (Thomas Charuhas) writes:
>I don't understand why everyone is so surprised. I was an avid Byte
>reader before it became a useless PC rag. ( > 5 years ago)

You have to remember who writes the checks.




-- 
Sean T. Lamont                           |   "Don't oppress me, It's
zeno@genetics.washington.edu             |    'computer of color!' "
lamont@abstractsoft.com                  |_______________________________
Abstract Software                                                         
Newsgroups: comp.sys.next.advocacy
From: schemers@leland.Stanford.EDU (Roland Schemers)
Subject: Re: NeXTSTEP on DEC Alpha?  Rumor in Digital News & Review
Organization: Distributed Computing Group, Stanford University
Date: Fri, 20 Nov 92 05:08:28 GMT

In article <1992Nov19.180100.23689@adobe.com> byer@adobe.com (Scott Byer) writes:
>Chuck (Non-Peon) Waltrip writes
>
>I find it difficult to believe this, since VMS requires some
>different microcode to be downloaded to the chip than OSF/1 does.
>It's easy enough to have the two OS's on a single disk and boot
>them up one at a time, but at the same time?  Not unless you do a
>very heavyweight task switch between OS's to re-download the required
>PALcode.

There was a paper in the last USENIX proceedings on micro-kernels
from someone at DEC who had got a hacked up VMS environment running on
top of the Mach 3.0 micro-kernel. It wasn't a complete VMS environment
but the basic VMS commands worked. 

The idea behind Mach 3.0 and/or micro-kernels is that OS's like VMS, Dos,
Mac, are just applications running on top of the micro-kernel. The PALcode
wouldn't have to change. 

Of course it will take a while for DEC to rewrite VMS so it uses a API
interface to a micro-kernel. Their current Open VMS is basically Macro
and Bliss code run through a translator with help from the PALcode on 
the Alpha.

Roland

-- 
Roland J. Schemers III              |            Networking Systems
Systems Programmer                  |            168 Pine Hall   (415)-723-6740
Distributed Computing Group         |            Stanford, CA 94305-4122
Stanford University                 |            schemers@Slapshot.Stanford.EDU
Newsgroups: comp.sys.next.advocacy
From: torrie@cs.stanford.edu (Evan Torrie)
Subject: Re: Where are they now?
Originator: torrie@Xenon.Stanford.EDU
Organization: CS Department, Stanford University, California, USA
Date: 22 Nov 92 02:49:38 GMT

gvh@metrosoft.com (Gordon Van Huizen) writes:

>In article <1992Nov17.094233.60912@cc.usu.edu> slhw4@cc.usu.edu (Jason  
>Hunsaker) writes:
>> What ever happened to Steve Wozinak (sp?) co-founder of Apple?
>> 

>He's in a PowerBook ad with his kid.

  According to the Mercury News, he is still an Apple fellow (one of
four, including Alan Kay).  As far as I can tell, being an Apple fellow
means Apple will give you practically whatever you want to do whatever
research you want to do.

-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu 
Embrace rationalism, reject superstition.           Break away from the past.
"...there is only one thing worse than having marketing people on a project,
 and that is having no marketing people on a project."  - Larry Tesler.
Newsgroups: comp.sys.next.advocacy
From: thomas@arnold.fkp.physik.th-darmstadt.de (Thomas Traexler)
Subject: Re: NeXTSTEP 486 Keyboard Question
Date: Mon, 23 Nov 1992 07:39:42 GMT
Organization: TH Darmstadt

In article <1992Nov19.233920.19537@pencom.com> ricardo@lush (Ricardo  
Parada) writes:
> I'm just curious.  Does anybody know how NS 486 handle the PC keyboard.   
> For instance, in the NeXT there is a Control, Alternate and Command.  On  
> the PC there is a Control and Alt key.  So what does NS 486 use for  
> Command?
On the PC are two Control and two Alt keys. So it is possible to use one  
Alt key as command (On the german PC keyboard the right Alt key is named  
Alt Gr and makes special characters), but I don t know how NS 486 handle  
the keyboard
Thomas
--
Thomas Traexler     Email:
TH-Darmstadt        thomas@arnold.fkp.physik.th-darmstadt.de  (NeXTmail)
Institut fuer         dd3i@mvs.hrz.th-darmstadt.de        (non NeXTmail)
Festkoerperphysik
Organization: Central Michigan University
Date: Tuesday, 17 Nov 1992 18:28:44 EST
From: John Goggan <34II5MT@CMUVM.CSV.CMICH.EDU>
Newsgroups: comp.sys.next.advocacy
Subject: Re: Really stupid Question: NS486 (WHEN??) - Q2 '92
 <1992Nov17.035458.188782@zeus.calpoly.edu>

When I asked the Michigan NeXT Rep. (Kent Foster) if the January date was
still valid, he said "no" and that it would most likely be around April,
plus or minus (which do _you_ think?!?) a month...

 - John Goggan (34ii5mt@cmuvm.csv.cmich.edu)
Newsgroups: comp.sys.next.hardware
From: toad@toadstool.UUCP (Kevin Cheek)
Subject: Syquest?
Organization: toadstool, Ann Arbor, MI
Date: Thu, 19 Nov 1992 08:35:52 GMT

	Does anyone use a Syquest drive on their NeXT? I'm thinking
about either a Syquest or a tape drive for my NeXTstation but I
thought I'd check for recommendations and personal experiences. I'm
leaning towards the Syquest due to what I would assume would be easier
(and faster) access to archived data and I don't really need to
backup anything besides my personal files since I have the CD-ROM
with the OS so the smaller capacity wouldm't be too much of a
problem for backups.

	If anyone can suggest sources for syquest drives and tape
drives, it would be very much appreciated. I've heard that Mac
suppliers are good for such things, but since most of my background
is in the PC world, I don't have much experience or knowledge of Mac
sources.

Please e-mail responses to me and I will summarize if there's
interest.

Thanks in advance for any advice/suggestions you can offer.

-- 
Kevin Cheek        --=NeXTMail OK!=--   |  Dawn, n.: The time when men
toad%toadstool@mudos.ann-arbor.mi.us    |         of reason go to bed.
toad%toadstool@plex-2.ann-arbor.mi.us   |           -- Ambrose Bierce,
toad@plex-1.ann-arbor.mi.us             |     "The Devil's Dictionary"
Newsgroups: comp.sys.next.hardware
From: bill@cvlab3.jsc.nasa.gov (Bill Hall)
Subject: Looking for a job....
Reply-To: bill@epnxt.jsc.nasa.gov
Organization: nasa-jsc
Date: Sun, 15 Nov 1992 20:34:03 GMT

Hello everyone.  As happens with government related jobs, layoffs come at this  
time of the year and after 10 years with the same company, I finally got cought  
in the budget crunch.  My company is very unhappy about loosing me but there  
just isn't any money.

If anyone knows of a company looking for an Electrcial Engineer with 10 years  
of solid hardware/software design in the biomedical field (not a paper pusher)  
and please let me know.  I also have 7 months programming on the NeXT (major  
projects) and extensive medical experience.

My phone is (713) 480-5152  (home)
or (713) 488-4102 (work... just ask for me).

On the net please reply to bill@epnxt,jsc.nasa.gov.  I have just upgraded to  
3.0 and am having problems sending mail out ... but not in recieving it.

	Bill Hall
Newsgroups: comp.sys.next.hardware