HDTenEightyP/NetNews huggingface dataset:
From: wierda@ltb.ltb.bso.nl (Gerben Wierda)
Newsgroups: comp.sys.next.advocacy
Subject: NeXT hardware strategy
Date: 6 Nov 92 08:52:16 GMT
Reply-To: gerben@rna.indiv.nluug.nl
Organization: BSO/LT, Baarn, The Netherlands

This is the situation NeXT is in (in my opinion):

	If NS486 is too cheap they won't sell any NeXT hardware anymore. They
will probably be having problems selling NeXT hardware as it is, because
companies normally go for secure buys, especially in recession. An 486 box is
a more secure hardware investment than a NeXT box.

	If NS486 is sold well, it will biuld an installed base that will give
the company more credibility. At that point they can more succesfully compete
with their own hardware.

	Pricing of NeXTSTEP 486 will drop as soon as NeXT has a machine that
is capable to outperform normal PC hardware more than it does already. (You
know, MIPS, SPECmarks and 'processor speeds' don't tell you very much. Try
running a PostScript animation on a NS486 486 50MHz DX box and you'll notice).

	I think it is almost the only sound strategy they could have come up
with. It now all depends on the speed and quality that NeXT can come up with
when executing this strategy.

[sidestep on]

Btw. I expect that the Pentium (when it arrives) will be register-starved and
have bugs. Since Moto processors are more elegant (generally speaking), I hope
they get their act together soon.

Did you ever wonder why Intel got together with NeXT? Simple: Microsoft tried
to be less depending on them (Ace, Alpha...).

Do I like industry watching!

[off]

I don't know anything of course, I'm just guessing.
-- 
wierda@ltb.bso.nl (Gerben Wierda)     ||    #include <std/disclaimer.h>. Support
NeXTmail: gerben@rna.indiv.nluug.nl   ||    the League for Programming Freedom!
    "If you don't know where you are going, any road will take you there."
    (From the Talmud(?), rephrased in) Lewis Carroll, "Alice in Wonderland".
Newsgroups: comp.sys.next.advocacy
From: jeffo@uiuc.edu (J.B. Nicholson-Owens)
Subject: Apologies
Reply-To: jeffo@uiuc.edu (J.B. Nicholson-Owens)
Organization: University of Illinois at Urbana
Date: Tue, 10 Nov 1992 05:56:14 GMT

I'm sorry to those of you who have to pay for news that you had to download my  
articles multiple times.  NewsGrazer kept coming back telling me that there was  
some problem with the posting mechanism on the nntp host I use for news and so  
I thought a little while later it would be okay.
-- 
-- Jeff (jeffo@uiuc.edu)
-- NeXTmail welcome
From: HWTQC@CUNYVM.BITNET
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiproces
Date: 11 Nov 92 13:58:03 GMT
Organization: City University of New York/ University Computer Center

> delete any unnecessary binaries

I don't quite understand this stuff, but if (say) the (unnecessary) 68040
binaries are deleted from the server because I login and access the app
from an as-yet-hypothetical-but-hoped-for NRW, then where does that leave
someone who then wants to access the app from a 68040 workstation?

just thinkin' while walkin' 'round...
-------
Harry Wert
Queens College Academic Computer Center
NeXT Mail: wert@alehouse.acc.qc.edu
From: ricardo@chuy (Ricardo Parada)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Date: 12 Nov 92 01:03:49 GMT
Organization: Pencom Software

In article <83161@ut-emx.uucp> ifbb657@cc.utexas.edu (Douglas Floyd)  
writes:
> OK, NeXT is using FatBinaries to do machine code for each processor.
> The bad thing about this is when NeXTStep runs on other processors,
> binaries must be compiled and included with the release.  P-Code is
> too S----L----O----W, and interpreting binaries is slllloooowwww also.
> 
> My solution:
> 
> NeXT code
> 
> Here is how it works:
> 
> 1:  Programmer codes his "killer app"
> 2:  C-compiler compiles the code into NeXTCode which is machine
>     independant, similar to Microsoft's P-code.
> 3:  When program gets to the user, the user uses an installer/
>     "compiler" to convert the NeXTCode to native machine code for
>     his processor.
> 
> Pros:
> 
> o Only one binary needed, no FatBinaries or ObeseBinaries
> o Runs LOTS faster than P-code or interpreted code
> o Easy to do
> 
> Cons:
> 
> Maybe some inefficency, but _very_ little.
> 
> Notes:
> 
> A special debugger can be produced to modify NeXTCode at the source
> for optomization
> 
> Patches to NeXTcode for different processors can be stored with the code
> 
> NeXT will have something no other computer has dreamed of offering :-)
> 
> COMMENTS ARE WELCOME- I would like to work on this as a discussion.
> 
> PS:  If NeXT is listening, and this helps, I am looking for a NeXT for
> my use to program some stuff :-).
> --
> ******* ifbb657@ccwf.cc.utexas.edu (Douglas R. Floyd) ******
>             Disclaimer: I speak for myself.
> 
>             Please, no NeXTMail at this time.

What would you suggest in the case where the application is being  
installed on a network where there are both 486 and '040 computers?   
Compile the code twice and end up with a fat binary?
There will be tools to strip out unneeded binaries from a fat binary.  

HOWEVER, your proposal "makes sense" if it will take less floppies to  
store the app than a fat binary.  Is this NeXTcode feasible without much  
hassle?

--
+ Ricardo J. Parada
Newsgroups: comp.sys.next.advocacy
From: raist@rmece02.upr.clu.edu (Ricardo Hernandez)
Subject: Re: Byte unfairness(?)
Organization: UPR-Mayaguez--ASEL Lab
Date: Wed, 11 Nov 1992 04:07:59 GMT

In article <1992Nov09.180447.193643@zeus.calpoly.edu>, mneideng@thidwick.acs.calpoly.edu (Mark Neidengard) writes:
|> Well, after having read the article in question, I was somewhat
|> disappointed, but not in the way the previous posters on this group were.  I
|> think that most people do not realize that computer mags, even Byte, are not
|> going to be the most objective institutions in the modern publishing milieu.
|> In comparison to the "PC" magazines, I find Byte to be the most informative,
|> and the LEAST biased.  For a mag that tries to cover everything from the
|> Amiga (augh) to the RS/6k's, I think they do a decent job.
   ^^^^^^^^^^^^^
   | Hey!  Watch it!  The respect I have for the NeXT has to do with 
     my objectiveness in recognizing good hardware, OS, etc. at a decent
     price... and the Amiga is great.

[stuff deleted]

|> 
|> Mark Neidengard
|> mneideng@cosmos.acs.calpoly.edu
|> NeXTmail to data.acs.calpoly.edu
|> "Is this a nightmare,
|>  Or the American Dream?"
|> 	Ice T
|> 
|> 

-- 
--------------------------------------------------------------
  Raist   // Amiga 500, 38Mhz Special MegaMidget Racer
        \X/  Avid user of AmigaVision, sending mail from Mayaguez, Puerto Rico 
---------
           "If the PC or Mac continues to be the standard,
            the SkyNet will never be built." - OUCH! were not my words!

Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.next.advocacy
Date: Wed, 11 Nov 1992 19:18:56 -0500 
From: Charles William Swiger <cs4w+@andrew.cmu.edu>
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.

Excerpts from netnews.comp.sys.next.advocacy: 11-Nov-92 Re: NeXT's
binaries need a .. by John Kheit@gandalf.rutge 
> I think that a good method is to compile the any app for all the
> different CPU's and put all of the versions in the .app wrapper.  When
> you double click on the app for the first time the machine figures out
> what CPU is being used and deletes all of the unecessary binaries in
> the wrapper.
>  
>         Or is this already the basic idea of FatBinaries?

Umm, not exactly.  Look, an executable program on the NeXT consists of
data (strings, numerical constants, tiffs, etc) and executable code (in
the __TEXT segment).  The data generally doesn't change regardless of
what CPU the code has been compiled for, but the executable code in the
__TEXT segment certainly will.  (I'm simplifing a bit; there are
possible alignment restrictions on the data that may vary between CPU's,
and so forth.  The basic idea is what counts.)

The idea of a "fat binary" is to make an executable that contains only
one version of the common stuff, and seperate versions of the
CPU-specific info.  When the program is executed, the system figures out
which CPU the system is and loads the appropriate pages.  The advantage
to doing this is the CPU specific stuff is only on the order of 30% or
so.  So a binary that works on 10 different CPU's would only be four
times as big as a binary that works on one, instead of being 10 times as
large.

This greatly simplifies administration of a heterogenous enviroment,
because you don't have to set up and maintain seperate areas for each
CPU.  You also don't worry about having different versions of a program
on different CPU's.

You can write a program similiar to "strip" that removes the executable
code of unwanted CPU's from a fat binary, so that an installed program
only occupies as much space as is necessary.

Fat binaries are a cool idea.  [nice grammar, here :-)]

-Chuck

+---------------------------------------------+ 
|  Charles William Swiger -- CMU sucks rocks  | "The television screen is the
|   AMS & normal mail: cs4w+@andrew.cmu.edu   | retina of the mind's eye."
|    NeXTmail: <temporarily out of order>     |           
+---------------------------------------------+            --Videodrome

Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc
From: gordie@yamanote.dolphin.com (Gordie Freedman)
Subject: BYTE article and my response to it
Reply-To: gordie@yamanote.dolphin.com
Organization: Dolphin Software
Date: Sun, 8 Nov 1992 06:43:36 GMT

I read the BYTE article and could not believe that they did such an unfair  
comparison with a low end (< $6000 monochrome) NeXT. My first reaction is  
to write them a nasty letter and pound my chest (figuratively speaking),  
however I do not think that will do anybody any good. It probably would  
not represent the NeXT community that well either.

I have instead written a letter which illustrates my concerns about the  
article, and gives them the benefit of the doubt somewhat. After all, I do  
not know the motivations and circumstances behind the article. On the one  
hand it seems like it is irresponsible to compare a $5000 machine to  
$25,000 machines, especially when the article can reach so many people who  
may not get much exposure to NeXTs and will base their opinions partly  
(totally?) on what they read. On the other hand, BYTE magazine may not  
have been given much help, or simply did not know enough about the NeXT to  
be able to do a fair comparison.

It doesn't really help much to argue with them about this. Instead, it is  
my hope that people in the NeXT community can write to BYTE magazine and  
explain how they may learn more about the NeXT, and possibly write more  
about it in future articles.

I can post my letter if anybody is interested, I am working on it now and  
am trying to walk that fine line between making my point clear, and being  
inoffensive. I hope that I will succeed somewhat but other people may be  
able to say things more eloquently than I do.
-- 
Gordie Freedman gordie@yamanote.dolphin.com   ->   NextMail encouraged
(Disclaimer: Opinions expressed are my own and represent no one else.)

Newsgroups: comp.sys.next.advocacy
From: esky@marathon.cs.ucla.edu (Eskandar Ensafi)
Subject: RISC -- what's the story?
Reply-To: esky@marathon.cs.ucla.edu
Organization: UCLA, Computer Science Department
Date: Thu, 12 Nov 92 22:26:37 GMT

Hi,

I haven't checked for new postings for the last month -- what are the RISC chip  
postings all about?  Has Motorola killed the 88110?

E-mail preferred.

Thanks!

- Eskandar
Newsgroups: comp.sys.next.advocacy
From: eps@futon.SFSU.EDU (Eric P. Scott)
Subject: Re: NeXT Prices: They appear too high for me!
Reply-To: eps@cs.sfsu.edu
Organization: San Francisco State University
Date: Tue, 10 Nov 1992 05:11:56 GMT

For any useful comparison between a Mac Quadra and a NeXT, you
need to figure in the price of A/UX 3.0 and the additional RAM
and disk requirements.  Then compare performance.

					-=EPS=-
From: lkingsley@crd.ge.com (Lorne J. Kingsley)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT edu prices go UP!  AGAIN!
Date: 6 Nov 92 21:06:06 GMT
Followup-To: comp.sys.next.advocacy
Organization: General Electric R&D

> Paul Burchard writes
> >>> After weeks of discussion of the need for cheaper machines, guess  
> >>> what?  The price here at Stanford for the cheapest available NeXT  
> >>> just went UP!
> >> 
> >> Well guess what?  I just got the latest price list and price have  
> >> increased AGAIN!
> > 
> > In this context you may be interested to note the following 
> > job annoucement from misc.jobs.offered.  Note the specific, 
> > repeated use of the word "low cost workstations" (as opposed 
> > to "high-performance workstations").  I will leave it to the 
> > c.s.n.a crowd to debate the implications....
> > 
> > + From: Dan_Smith@NeXT.COM (Dan Smith)
> > + Subject: Hardware Design Engineer - NeXT Computer - Redwood City
> > + 
> > + Participate in the design of low-cost workstation products
>                                  *****************************

I think the obvious challenge here is to have NeXT _define_ low-cost. Our
definition of low-cost undoubtedly does not agree with NeXT's. They may
feel that their current crop of low-end CPUs are "low cost". 

At least that's what the NeXT rep who has been courting us has been
chanting...

- Lorne

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Lorne J. Kingsley                                  General Electric Company
---->My opinions don't represent those of the General Electric Company<----
Internet: lkingsley@crd.ge.com        CI$: 75166,2550         AOL:MacReport
From: cs4w+@andrew.cmu.edu (Charles William Swiger)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Date: 7 Nov 92 12:48:32 GMT
Article-I.D.: andrew.Aez4T0i00Uh_037rxp
Organization: Senior, Chemistry, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.next.advocacy: 6-Nov-92 NeXT's binaries
need a diet.. by Douglas Floyd@cc.utexas. 
> Here is how it works:
>  
> 1:  Programmer codes his "killer app"
> 2:  C-compiler compiles the code into NeXTCode which is machine
>     independant, similar to Microsoft's P-code.
> 3:  When program gets to the user, the user uses an installer/
>     "compiler" to convert the NeXTCode to native machine code for
>     his processor.

Basically, you want to dump out the Abstract Syntax Tree (AST) after
compiling, some optimization, and before register allocation.  Take a
look at the -d<letter> option in gcc.

Problems:

1)  You still have to do register allocation and generate assembly from
the AST, and then perform peephole optimization to catch processor
pecularities.  Then you have to link the code together.  This would take
a considerable amount of time (on the same order as the amount of time
needed to do a full compile from the source code.)  Gcc can't do this
now, but it would be fairly easily doable.

2)  At this stage, you can reconstruct the source code from the AST
without losing anything more than local variable names and static
function names.  For a commercial product, this is no different than
providing the source code to their product.  This is a major problem,
and one that I don't believe is solvable.

3)  It's not necessary, either.  The install procedure could offer an
option to strip the unneeded binary images for other processors, leaving
only a "thin binary".  It's why "fat binaries" are looking like the way
to go.

-Chuck

+---------------------------------------------+ 
|  Charles William Swiger -- CMU sucks rocks  | "The television screen is the
|   AMS & normal mail: cs4w+@andrew.cmu.edu   | retina of the mind's eye."
|    NeXTmail: <temporarily out of order>     |           
+---------------------------------------------+            --Videodrome
Newsgroups: comp.sys.next.advocacy
From: nathan@laplace.biology.yale.edu (Nathan F. Janette)
Subject: Re: NeXT edu prices go UP!  AGAIN!
Reply-To: nathan@laplace.biology.yale.edu
Organization: Yale University, Department of Computer Science, New Haven, CT
Date: Fri, 6 Nov 1992 20:05:13 GMT

In article <1992Nov6.083834.4422@leland.Stanford.EDU>  
spagiola@frinext.stanford.edu (Stefano Pagiola) writes:

> Now consider two options.  Both are marketing choices, note, and do  
> not require any additional development.

> 1. Continue selling something like the 8/105 25MHz slab, at a price  
> somewhat lower than its price 2 years ago of $3150.

> 1. (slight variant) As above, but provide a slightly better  
> configured machine; perhaps by increasing the HD to 200MB.

I think the 25 MHz 2-bit greyscale systems have plenty
enough muscle for single users, given a proper amount of
RAM and HD. A NeXTstation 16/250 for at most the same price
as the 8/105 used to be ($4,995 list, $3,500 edu) would
offer users an entry-level NeXT machine for a price that
shows NeXT is aware that it's competitors have been
lowering their prices in the time since the NeXTstation
first shipped, and also would represent the claimed cost
savings of the new motherboard and components.   

I'd like to see the 33 MHz system priced about $500 above
that, and the expected 40 MHz system another $500 above
that.

I'd also like to see the color systems slide down to $1,000
above a similarly configured greyscale system. 

It's also time to lower the price of the laser printer,
which also has plenty of lower priced competition, not
the least of which is the brand new 600 DPI HP LJ4.

That would give the following basic system configurations:

NeXTstation Greyscale 25 MHz 16/250 $5000/$3500
NeXTstation Greyscale 33 MHz 16/250 $5500/$4000
NeXTstation Greyscale 40 MHz 16/250 $6000/$4500

NeXTstation Color 25 MHz 16/250 $6000/$4500
NeXTstation Color 33 MHz 16/250 $6500/$5000
NeXTstation Color 40 MHz 16/250 $7000/$5500

--
Nathan Janette		"I'm a NeXTstep man,
Dept MB&B, Yale Univ	 I'm a NeXTcube guy"
New Haven, CT
nathan@laplace.biology.yale.edu (NeXT)
From: billabs@nic.cerf.net (Bill Romanowski)
Newsgroups: comp.sys.next.advocacy
Subject: I take it back
Date: 14 Nov 92 02:07:19 GMT
Followup-To: Snake Oil and Lost Love
Organization: CERFnet

A few weeks ago I posted some gripes about NeXT. Well.....
I've just completed a week at Dev Camp in Chicago. It was
great++. The NeXT people were top notch and material presented
was also of the highest quality. Ahhh! Enlightenment!!

The class contained no NeXT religion beyond what is embodied
in design of the system software architects.

I now understand that the NeXT vision goes far beyond the physical 
world of the machine. It'll be great when bigger/faster/better
machines come out but after seeing it all more clearly, NeXTSTEP has 
me re-thinking all aspects of how I design for -any- platform. 
Everything else now seems years behind the times. 

Sorry NeXT, I take it all back.

bill romanowski
prairie research
From: ifbb657@ccwf.cc.utexas.edu (Douglas Floyd)
Newsgroups: comp.sys.next.advocacy
Subject: NeXT versus Sun
Date: 5 Nov 92 21:21:49 GMT
Reply-To: ifbb657@ccwf.cc.utexas.edu (Douglas Floyd)
Organization: The University of Texas at Austin, Austin TX
Originator: ifbb657@grumpy.cc.utexas.edu


  Here is a little tidbit. Even when there are no other users on the
Sun Sparc 1+'s that they have at UT (University of Texas), the NeXT
system they have always seems faster than the Suns.  Is SunOS clumsy,
or is NeXTStep work really well on the '040?

I know that Sun's windowing system sucks doggie cookies, but why is
logging on and off the Suns so sllllooooowwww compared to logging
onto the NeXT?  (UT's NeXT is an original NeXTCube upgraded to a NeXTDimension
with two monitors and the MO drive.)

PS:  The Suns have the Sparc chips in them, no 68030s.

-- 
******* ifbb657@ccwf.cc.utexas.edu (Douglas R. Floyd) ******
Disclaimer: I speak for myself.
Win NT:     Prophesied in the Bible as one of the signs that the
            world is about to end.
Newsgroups: comp.sys.next.advocacy
From: byer@adobe.com (Scott Byer)
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Reply-To: byer@adobe.com (Scott Byer)
Organization: Adobe Systems Incorporated
Date: Wed, 11 Nov 1992 19:47:06 GMT

John Kheit writes

> I think that a good method is to compile the any app for all the
> different CPU's and put all of the versions in the '.app' wrapper.
> When you double click on the app for the first time the machine
> figures out what CPU is being used and deletes all of the unecessary
> binaries in the wrapper.

> 	Or is this already the basic idea of FatBinaries?

Close.  The different binaries are contained within labelled Mach-O
segments.  The right '__TEXT' section is pulled in by the loader.
If you're careful, and the compiler/linker are smart enough, the
'__TEXT->__text' segment is the only one that has to be different
for different machines.

You will get maybe a 20% size increase for *each* additional
processor, based on typical application usage of data/nib/code.

You will also have the option of stripping the binary to a single
processor version for a local install.

Personally, I think the FatBinary solution is a simple, elegant
solution.  I can go to the store and buy one package labelled 'NeXT'
instead of having to look for any processor type sticker.  Nor do
manufacturers have to have extra floppies that contain large amounts
of duplicate data (if you had a full application per processor).

And (!) not only do FatBinaries effectively solve the server to
different processors problem, it solves the problem of single
machine with multiple disparate processors - when you start up the
app, Mach can run the app on whichever processor has the lowest
load, using the machine far more effectively.

--
Scott Byer                             NeXTMail: byer@mv.us.adobe.com
Adobe Systems Incorporated               These are *my* opinions, and  
1585 Charleston Road, P.O. Box 7900        do not necessarily reflect
Mountain View, CA 94039-7900             the opinions of my employer.
---------------------------------------------------------------------
Newsgroups: comp.sys.next.advocacy
From: Joseph R. Grace <JGrace@TetraSoft.com>
Subject: Re: NeXT edu prices go UP!  AGAIN!
Organization: TetraSoft International
Date: Fri, 6 Nov 1992 17:30:05 GMT

In article <1992Nov6.083834.4422@leland.Stanford.EDU>  
spagiola@frinext.stanford.edu (Stefano Pagiola) writes: 
>  [Much insight deleted :-]
>  Consider the removal of all systems less powerful than the Turbo Slab  
>  16/250 from the edu price list (at least here at Stanford; has this  
>  occurred anywhere else?).  This is clearly a marketing decision.
>  [Even more insight deleted! :-]

I agree with the general interpretation, but I *can* conceive of another  
(overly hopeful and probably misinformed, I fear) reason.  Perhaps NeXT's  
factory can handle only 2 different "calibre" (insert violent hand-waving :-)  
machines at a time.  Were that true, NeXT could be dropping the old "calibre"  
CPU's to make room on the production line for the new (NRW) calibre CPU's.

YAY!  It sounds so good, it *must* be true!  WEEEeeeeEEEE!

Comments?  (No flames, please --- it's just a thought!  :-)

= Joe =

-- 
Joe Grace <JGrace@TetraSoft.com> (NeXTMail preferred.)
TetraSoft International   Business and Personal Productivity Tools for NeXTSTEP