Path: utzoo!attcan!uunet!decwrl!shelby!daemon From: lane@sumex-aim.stanford.edu (Christopher Lane) Newsgroups: comp.sys.next Subject: re: What NeXT *should* do next. Message-ID: <1385@shelby.Stanford.EDU> Date: 26 Mar 90 18:02:05 GMT Sender: daemon@shelby.Stanford.EDU Lines: 106 Wow, 14 replies in under 72 hours! I didn't intend to start that many flames--now for just a little more kerosene: \begin{opinion defense} Most replies seemed to concentrate on the 'RISC' part of my original posting which I think is only one of several issues. The three things I see over and over (from current and potential NeXT owners) in this news group are: 1) There are not enough third-party products for the NeXT. 2) Is the company stable--will it be around after I buy the machine? 3) The machine's too slow. The use of the new IBM chip would solve all three problems, not just the third. What would attract more third-party developers are more potential customers. I guess that even if the new IBM machines do 'poorly' they will easily equal or outsell all the NeXTs to date. Doubling or tripling the number of NeXTStep users will do more to make third party products available and improve the outlook of NeXT's survival than just improving the speed of the machine. As far as machine speed goes, 20 MIPS seems to be a reasonable minimum and what we can probably expect from a 68040-based NeXT. But remember, when the NeXT was first introduced it seemed like it had more than enough power until it became clear the more powerful softare (like Display PostScript) would easily consume the cycles. Hopefully, even more powerful sofware will easily consume the cycles on the next NeXT! I'm more concerned with what comes after--can we again expect the follow on to the 68040 to show up a year and a half to two years after the first in depth article on it shows up? Will that be soon enough or will we all be waiting intensely again? I believe the newer architectures will do better at providing significant performance improvements on a regular basis--I don't believe the propaganda that RISC is inherently better than CISC; the latter has benefited from new ideas first tried out using the former but there are no formal proofs yet with respect to instruction sets. As unpopular and as unlikely as it is, I think that NeXT making use of the new IBM RISC CPU along with NeXTStep under AIX will solve all three major problems. In addition, an important one as far as the systems we develop is concerned, it will provide a range of NeXTStep platforms from which to choose (trading off price vs. performance) when delivering a completed (in our case expert, medical) system. In general, I agree with the various comments that the next NeXT utilizing the more powerful Motorola's DSP chip and having more, denser memory. Some specific replies: In <1990Mar23.225518.21224@aqdata.uucp>, sullivan@aqdata.uucp writes: >Jobs may license NextStep to IBM but I doubt he's going to let NeXT depend >on IBM for the CPU. Being able to easily move between CPUS and getting NeXT users to multiple CPUs early (not using the Sun model but rather a multiply targeted binary) will free NeXT from being held hostage by one CPU maker (IBM) or another (Motorola). In , fischer@iesd.auc.dk writes: >Not that it's really an issue. o you really believe that IBM will let >you get their chip? Did you ever see IBM selling RAM chips? My recollection is that when the new IBM line came out there was an article, quoting an IBM person, about IBM's interest in having other vendors build machines around their new chip, mentioning NeXT by name as an example of a company that will eventually need a RISC chip. If I (re)locate the article, I will send you a citation for it. In <424@toaster.SFSU.EDU>, eps@toaster.sfsu.edu writes: >RISC architecture may be faster on simple benchmarks, but let's get >realistic: it's a *memory hog*. Your performance is going to suck >without a lot more RAM than you're probably willing to pay for, >faster backing store than you can afford, plus you're going to >need more disk space for all your executables, even with everything >linked against shared libraries. If one assumes that SPARC is typical of a RISC architecture, then do 'ls -l' on /bin on a (680X0) Sun3 vs. a (SPARC) Sun4--the difference is < 10%. Can the memory difference be much more? Look at /bin on the NeXT, 'who' takes up more (disk) space than 'who' on the Sun3 and Sun4 combined! Other system choices can have more effect on disk space consumption than just the instruction set. Of course, one could also strip the segments for other architectures if one really wanted to save the space. In <26849@ut-emx.UUCP>, chari@ut-emx.uucp writes: >You might have overlooked that fact that IBM uses the not so elegant >AIX not Mach so, the object files format is different. So, your >segment idea kind of loses there. The multiple segment binary was mainly to address multiple architecture NeXTs. However, my understanding is that OSF's Unix will derive most of its code from AIX but will be built on Mach--can AIX on Mach or OSF on RS/6000 be far behind? In the worst a case, one just has to have the reverse of 'atom' to clean up the binaries. >Having the same binaries on the two machines is pointless anyway. What >standard medium exists by which one could move files between the two machines? Ethernet? \end{opinion defense} - Christopher -------