HDTenEightyP/NetNews huggingface dataset:
From: mrothste@keiko.acs.calpoly.edu (Rothstein)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Date: 11 Nov 92 03:19:17 GMT
Article-I.D.: zeus.1992Nov11.031917.153777
Reply-To: mrothste@data.acs.calpoly.edu
Organization: Cal Poly State University, San Luis Obispo

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.


As I understand it there is a very good reason NeXT is using Fat Binaries,  
multi-cpu networks.  They want you to be able to have one server for a  
NeXTwork with NeXT machines, and NS 486 machines, etc.  If you have a  
NeXTwork with only one type of machine or a standalone then you can put  
the code on a "diet" and strip out the unneeded code.  Also Fat Binaries  
are only ~20% larger (or so I hear).  I also got the feeling that the code  
choice was so low level as to not create a speed degredation.

--
-Mont

   NeXTmail OK :-)
   President CP-NUG (Cal Poly NeXT User Group)
   mrothste@data.acs.calpoly.edu
Newsgroups: comp.sys.next.advocacy
From: philip@utstat.uucp (Philip McDunnough)
Subject: Re: NeXT edu prices go UP!  AGAIN!
Organization: University of Toronto, Dept. of Statistics
Date: Tue, 10 Nov 1992 11:40:35 GMT

In article <1992Nov8.045644.6863@cubetech.com> andrew@cubetech.com writes:

[ ]
>
>Believe me when I say that people at NeXT marketing want NeXT to be
>come the next Microsoft.  Yeah I wish they would put out superbowl
>commercials and such like you do, but apparently that's not possible.
>It also probably wouldn't do any good too since NeXT has sort of a bad
>stigma attached to it from the '030 days.  People don't belive
>marketing unless there is something to back it up.  Microsoft
>advertises more than anyone else, and people buy their software in
>droves, but only because "well Bob has it, so it can't be that bad!"
>Not so with NeXT.  NeXT screwed up (unintentionally) the first time at
>bat, and now they have to fix it the hard way.

Microsoft writes software that can run on computers that are accessible 
to a large proportion of people. This is not the case with NeXT. In fact 
when one thinks of it, just what market could NeXT be aiming for? They 
don't have a high end computer so that scientists (who largely need fast
computers to run simulations of models developed without the aid of IB and
certainly not with any MCA approach) don't need them except possibly for the
built in TeX and Mathematica (which one can get elsewhere, and in any case
there's more to symbolic algebra than Mathematica). They don't have an entry
level computer so that students can't afford them. This cuts off innovative
energetic input. What does that leave? No reasonable multimedia solution. There
isn't even a reasonable sequencing/notational program that comes close to the
Mac/Atari offerings. One could argue that you could use the NeXT as a frontend
to information collection, but the Mac and even a PC running OS/2 are better
solutions that the NeXT for that. Even  if not better now, they will be in 6
months.
 
The original NeXT was full of promise, ideas, etc...One can hardly call this
a mistake. The world doesn't need yet another workstation. In particular, the
world doesn't yet another workstation witout a bus. The NeXT Stations may
be the only computers NeXT wishes to sell at this point, but their lack of
support for the Cube's expansion capabilities will come back to haunt them.

Philip McDunnough
University of Toronto
philip@utstat.toronto.edu
Newsgroups: comp.sys.next.advocacy
From: lemson@ux1.cso.uiuc.edu (David Lemson)
Subject: Re: NeXTs shipping sooner than Quadras?
Keywords: irony
Organization: University of Illinois at Urbana
Date: Fri, 6 Nov 1992 00:26:57 GMT

matthews@ecfa.jsc.nasa.gov (Michael C. Matthews) writes:

>I can only assume Roper & company haven't ordered a NeXT CD-ROM drive
>yet... :-)  What I find amazing is that they were able to get their
>hands on a NeXTstation in less than 3 months.  Of course, it's been
>18 months since I bought hardware from NeXT (other than the CD-ROM
>drive I'm waiting for), so maybe they're getting machines out the
>door faster now.

Yes, lead times on NeXTStations ('normal' configurations) are
usually under 6 weeks.  It is when NeXT depends on products
manufactured by other parties (say... Sony....) that they get in
trouble.

Also, sometimes we (UIUC) keep some stock because there is a fair
demand on this campus. 
-- 
David Lemson                                                (217) 244-1205
University of Illinois NeXT Campus Consultant / CCSO NeXT Lab System Admin
Internet : lemson@uiuc.edu                UUCP :...!uiucuxc!uiucux1!lemson 
NeXTMail accepted                                  BITNET : LEMSON@UIUCVMD
Newsgroups: comp.sys.next.advocacy
From: nevin@dtint.dtint.com
Subject: Re: DEC's alpha is "way fast" according to WSJournal
Reply-To: nevin@dtint.dtint.com
Organization: Digital Technology, International
Date: Fri, 13 Nov 92 07:26:31 GMT

> I don't see a major revolution occurring with the transition between
> 32-bit and 64-bit processors because the computer industry really hasn't
> max'ed out the possibilities of 32-bit machines yet.  (How many people
> do you know have complained that their machines can only address 4 gigs
> at a time?  Anyone ever seen a machine with more than 4 gigs?  Cray
> YMP's in your local supercomputing center, perhaps, but not machines
> intended for the consumer market.)
> 
> -Chuck
> 
> +------------------------------------------+ "Foosh.  Aaughh!!"
> | Charles William Swiger -- CMU...crunch!  | "Foosh.  Aauuggghh!!"
> | AMS & normal mail: cs4w+@andrew.cmu.edu  | "Cold spray deodorant...."
> | NeXTmail: chuck@mon.slip.andrew.cmu.edu  |
> +------------------------------------------+   -- Opus, Bloom County [RIP]

The CPU addresses *virtual* memory; the MMU translates those virtual addresses
to real addresses.

While 4 gigabytes of usable virtual memory seems large right now, there are
many high-end workstations that are beginning to bump into this limit.

Thus, the eventual transition to 64-bit processors in inevitable.

--
Nevin Pratt, Digital Technology, Int'l    Orem, Ut
NeXTmail preferred, but ONLY at my REAL email address: nevin@dtint.dtint.com

-- 
---
root	                               root@dtint.dtint.com
Digital Technology Int.                (801)226-2984	
500 W. 1200 South, Orem UT, 84057      FAX (801) 226-8438
From: carsten@pizza.fb10.tu-berlin.de (Carsten Schultz)
Newsgroups: comp.sys.next.advocacy
Subject: SORRY
Date: 11 Nov 1992 15:15:34 GMT
Organization: ZRZ/TU-Berlin
Distribution: world
Reply-To: carsten@pizza.fb10.tu-berlin.de (Carsten Schultz)
NNTP-Posting-Host: pizza.fb10.tu-berlin.de


Hi folks,

I'm really sorry for the large number of ugly postings above, but  
NewsGrazer kept on telling me, that it did not successfully post MHO.

Sorry,

Carsten
Newsgroups: comp.sys.next.advocacy
From: gvh@metrosoft.com (Gordon Van Huizen)
Newsgroups: comp.sys.next.advocacy
Subject: Re: SORRY
Date: 12 Nov 92 17:53:50 GMT
Reply-To: gvh@metrosoft.com (Gordon Van Huizen)
Organization: Metrosoft

In article <1dr82mINNba6@mailgzrz.TU-Berlin.DE>  
carsten@pizza.fb10.tu-berlin.de (Carsten Schultz) writes:
> 
> Hi folks,
> 
> I'm really sorry for the large number of ugly postings above, but  
> NewsGrazer kept on telling me, that it did not successfully post MHO.
> 
> Sorry,
> 
> Carsten

Hey it was kinda fun to watch it keep growing by a line! :-)

-- 
----------------------------------------------------------------
Gordon Van Huizen           vox: 619.488.9411  fax: 619.488.3045
Metrosoft                   gvh@metrosoft.com [NeXTmail welcome]
----------------------------------------------------------------
Newsgroups: comp.sys.next.advocacy
From: basiji@stein.u.washington.edu (David Basiji)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT edu prices go UP!
Date: 5 Nov 92 16:56:52 GMT
Article-I.D.: u.1992Nov5.165652.15458
Organization: University of Washington


[perceptive analysis of cost/benefits for entry level edu NeXTs deleted]

It seems that NeXT Inc. is forsaking the small edu user for the large business
and government contracts.  $4400 for an entry level system is well beyond
the realm of the reasonable for students and small educational labs, given
today's market.  I used to recommend NeXTs to my fellow grad students until
the prices went up at our bookstore. 

NeXT Inc. seems to have forgotten that low- and no-profit machines for edu
users will generate brand loyalty when these folks get out into the real
world and have some say in business purchase decisions that generate profits
for NeXT Inc.

David Basiji
From: eht@cmu.edu (Eric Thayer)
Newsgroups: comp.sys.next.advocacy
Subject: Re: Byte Magazine pans the NeXTstation
Date: 11 Nov 92 16:54:00 GMT
Article-I.D.: cs.BxK9M2.4qA.2
Organization: School of Computer Science, Carnegie Mellon

In article <175@bytepb.UUCP> ben@bytepb.UUCP (Ben Smith @ BYTE) writes:
> For heterogenous UNIX
> computing I prefer something that uses X as a matter of course
> and which relies more on standards (such as RFC822 for mail). 

Yes, you do not get X out of the box as in other Unix workstations.   However,  
I'm confused about the remark about RFC822.  I routinely send mail to and get
mail from many users on the Internet.  Yes, NeXT attachments and RTF messages  
get encoded into an unreadable mess if you send it to a non-NeXT machine, but  
if you stay away from using the NeXT enhancements for non-NeXT mailboxes,  
things have worked flawlessly for me since the 0.8 days.

..eric
Lines: 72
From: wln@cs.columbia.edu (William Lee Nussbaum)
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Organization: Columbia University Department of Computer Science
Date: Sat, 7 Nov 1992 20:02:43 GMT

In article <TTN.92Nov7113048@kivikkorastas.cs.tut.fi> ttn@cs.tut.fi (Tero Nieminen) writes:
>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:
>
>[deteted a solution of hadware independent intermediate code]
>
>Probably what they will do is to shi a utility to strip unnecessary
>binaries out. This way users won't need to compile anything or even keep
>the compiler on their disks. It might make it more difficult for the
>programmer to support all platforms, though.
>-- 
>         Tero Nieminen                      DANGER!
>         ttn@cs.tut.fi                   Computer Bytes!

NeXT has already stated that the versions of the OS that ship at
486-time will have utilities to strip fat binaries down to size.

GCC cross-compiles rather happily if you have appropriate headers and
libraries.  Given that both OSes will be NeXT's, it won't be too
difficult for them to make sure that things cross-compile happily.
From: marcel@opal.cs.tu-berlin.de (Marcel Weiher)
Newsgroups: comp.sys.next.advocacy
Subject: Re: DEC's alpha is "way fast" according to WSJournal
Date: 13 Nov 92 19:43:21 GMT
Organization: Techn. University of Berlin, Germany

nevin@dtint.dtint.com writes:

>> I don't see a major revolution occurring with the transition between
>> 32-bit and 64-bit processors because the computer industry really hasn't
>> max'ed out the possibilities of 32-bit machines yet.  (How many people
>> do you know have complained that their machines can only address 4 gigs
>> at a time?  Anyone ever seen a machine with more than 4 gigs?  Cray
>> YMP's in your local supercomputing center, perhaps, but not machines
>> intended for the consumer market.)
>> 
>> -Chuck
>
>While 4 gigabytes of usable virtual memory seems large right now, there are
>many high-end workstations that are beginning to bump into this limit.
>
>Thus, the eventual transition to 64-bit processors in inevitable.

I can only second that.  I have an application that currently requires
about half a gig of memory.  With current NeXTs, I have to split it
up and do it several times, limiting throughput and performance and 
also decreasing reliability/compatability.

Marcel
Newsgroups: comp.sys.next.advocacy
From: lytras@avalon.physik.unizh.ch (Apostolos Lytras)
Subject: Re: NeXT Prices: They appear too high for me!
Organization: Informatik Club d. Universitaet, Zuerich
Date: Tue, 10 Nov 1992 15:00:35 GMT

In article <1992Nov10.051156.2995@csus.edu> eps@cs.sfsu.edu writes:
>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.

Given that Apple itself prices its products _far_ too high, he is right
comparing the two. Of course he does not get a product where (value =
cost) from either vendor, and that means he's right pointing out that
NeXT's are too expensive (and getting ever more so). The sad part of the
story is now, that for an European student (such as me) SPARC-based
systems come in at *HALF* the price of a comparable NeXT, and as a
student is not really depending on a fancy user interface, that *is* an
argument for switching from NeXT to other vendors. Sadly enough, NeXT
seems to have found its marketing idol in Apple (overpriced & nothing
but a beautiful GUI), and seems to be bound to give up on the
educational markets. I really like my NeXT, but I'll have to sell it,
because others give me the opportunity of having a comparable machine
AND some money on the side. NeXT just isn't concerned with "us" any
more, that's what I think the original poster wanted to express, and
he's dead right.

Cheers
- A.


-- 
	 lytras@ifi.unizh.ch   		|   Apostolos Lytras
	 lytras@avalon.physik.unizh.ch	|   Informatik Club der Uni
	 lytras@amiga.physik.unizh.ch  	|   Zuerich, SysAdmin
From: carsten@pizza.fb10.tu-berlin.de (Carsten Schultz)
Newsgroups: comp.sys.next.advocacy
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Date: 11 Nov 1992 15:09:46 GMT
Organization: ZRZ/TU-Berlin
Distribution: world
Reply-To: carsten@pizza.fb10.tu-berlin.de (Carsten Schultz)
NNTP-Posting-Host: pizza.fb10.tu-berlin.de

In article <Nov.11.01.37.01.1992.26014@gandalf.rutgers.edu>  
szatrows@gandalf.rutgers.edu (John Kheit) writes:
.. 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.

Well this might be a nice option, but not useful for everyone. Please do  
not forget that there might be networks with different CPUed (what a word)  
computers.

Carsten
Newsgroups: comp.sys.next.advocacy
From: schock@flip.cpsc.ucalgary.ca (Craig-Richard Schock)
Subject: Re: Byte Magazine pans the NeXTstation
Reply-To: schock@flip.cpsc.ucalgary.ca
Organization: University of Calgary Computer Science
Date: Fri, 13 Nov 1992 23:29:07 GMT

In article <175@bytepb.UUCP> ben@bytepb.UUCP (Ben Smith @ BYTE) writes:
> pgriffin@uful07.phys.ufl.edu (Paul A. Griffin) writes:

> But, it does not work in a mixed environment. (Nor
> does the Mac or PC, for that matter.) 

The NeXT I'm working on right now has been in a mixed environment for 2 years  
now.  I think you just need better system maintainers.


>For heterogenous UNIX computing I prefer something that uses X as a matter of  
>course and which relies more on standards (such as RFC822 for mail). 

In article <BxK9M2.4qA.2@cs.cmu.edu> eht@cmu.edu (Eric Thayer) comments:
> Yes, you do not get X out of the box as in other Unix workstations.    
>However, I'm confused about the remark about RFC822.  I routinely send mail  
>to and get mail from many users on the Internet.  Yes, NeXT attachments and  
>RTF messages get encoded into an unreadable mess if you send it to a non-NeXT  
>machine, but if you stay away from using the NeXT enhancements for non-NeXT  
>mailboxes, things have worked flawlessly for me since the 0.8 days.

I agree... I'm confused about that RFC822 comment too.  I haven't seen the  
spec for some time... what Specifically in the spec does the NeXT not comply  
with?


> As you must realize, it is impossible to do a "scientific" comparison
> of systems that have not only different CPUs, but also different OSs
> and user interfaces. 
So, what you're really saying is that it's a waste of time to do such a  
useless comparison.  But BYTE magazine did so anyway.  Hmmm...  It seems that  
BYTE is more of a Tabloid rather than a magazine.  When do we start seeing the  
stories about mutant User Interfaces Killing Users in Ohio or how about the  
68090 chip which, as a result of a clever time warp, ended up in a Vic 20  
making it the MostSuperAwesome Computer of the 90's.  

>The only way to evaluate this spectrum is call
> them as we see them, and that is what we did. There is as much
> personal opinion in this kind of comparison as there is any
> statistics; perhaps even more.

If erroneously reporting information is "calling them as you see them", then  
you not only look silly, but you lose a great deal of credibility as well.

Craig
Newsgroups: comp.sys.next.advocacy
From: Joseph R. Grace <JGrace@TetraSoft.com>
Subject: DEC's alpha is "way fast" according to WSJournal
Organization: TetraSoft International
Date: Tue, 10 Nov 1992 21:50:30 GMT

Well actually, that's not the quotation ;-)  The *real* quotation is even worse  
( :-) and follows:

The Wall Street Journal, Tuesday, November 10, 1992, page B4, John R. Wilke,  
staff reporter of The Wall Street Journal.

  Digital's Alpha chip is a technical departure from much of the rest of the
  field, capable of swallowing 64 bits of data at once, or four billion times 
  as much data as the 32-bit chips championed by competitors.

WHOA --- that's way fast I/O!  (Me again.  :-)  I guess it has a hidden mode  
which DEC has kept under wraps until the machines's introduction today.   
Frankly I'm amazed. :-)

Seriously, John seems to have missed the boat on this one.  He follows that  
line with: "But rivals doubt it provides much of an edge, arguing there are few  
programs that can use all the added capability."  Sheesh John, I know  
journalists like to hedge but couldn't you just do a dummy check on your own  
information?  You can't!?  Sorry for asking ;-)

You'ld think I would have learned by the end of the elections to be a little (a  
lot?) skeptical of the media...  [Don't quote me on that! :-]

Forever naive,

= Joe =

-- 
Joe Grace <JGrace@TetraSoft.com> (NeXTMail preferred.)
TetraSoft International   Business and Personal Productivity Tools for NeXTSTEP
Newsgroups: comp.sys.next.advocacy
From: jfr@RedBrick.COM ()
Subject: Re: NeXT's binaries need a diet, or the solution to NeXT's multiprocessor problem.
Organization: Red Brick Systems, Los Gatos, CA
Date: Thu, 12 Nov 1992 06:06:04 GMT

In article <Uf0O=ke00iV148FM5f@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> writes:
>Excerpts from netnews.comp.sys.next.advocacy: 11-Nov-92 Re: NeXT's
>binaries need a .. by John Kheit@gandalf.rutge 
>>         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.

  Indeed fat binaries are a "cool" idea.  I just question your 30%
  figure.  Do you have this on some authority from somewhere?   

  I can not imagine that fat binaries aren't easily 80-90% machine
  dependent.  Practically nothing you mentioned above (strings,
  numerical constants, tiffs, etc) not to mention code is easily
  machine independent.  I guess strings MIGHT be, but numerical
  constants certainly aren't unless there is someway of doing
  all the necessary byte and bit swapping when you load the module
  (for instance 680x0s and 80x86s have different endian and 
  byte swap requirements), and floating point constants are also
  probably different from machine to machine.  Any constant
  data structures might have alignment differences (you mentioned
  that but made light of it).  More importantly, I would doubt
  that a binary is only composed of 30% code, probably more like
  80% at the least.        

  As a side note, what happens to object archive files?  Are they
  portable across environments?  If so, how is this handled?  Does
  the 486 AppKit adapt to the 680x0 object format when loading and
  writing object archives?  If not, what happens if I try to
  initialize a 486 application with the nib file from a 680x0
  IB session?  

  Jon Rosen
Newsgroups: comp.sys.next.advocacy
From: steveh@rtsg.mot.com (Steve M. Hoffman)
Subject: Re: The Date of NeXTWORLD Expo
Organization: Motorola Inc., International Cellular Subscriber Group, GSM.
Date: Mon, 9 Nov 1992 16:36:44 GMT

In article <23690@galaxy.ucr.edu> mikes@velo.ucr.edu (Mike Shebanek) writes:
>I wondered when the next NeXTWORLD EXPO would be held and I couldn't get any  
>answers from NeXT so I called Moscone Center in San Francisco.  They told me  
>they had a "NeXT EXPO" on the books for May 25-28.

Nice piece of investigation!  Looks like we also know about when we should
hear about some new hardware too...  Nitro and/or NRW?  Well, looks like we'll
have to wait until then to find out!  Later!
-- 
Steve Hoffman <steveh@rtsg.mot.com>
Motorola Inc. Arlington Heights, IL
All opinions are my own.
Big corporations have none.