Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: Re: A3000UX competition Message-ID: <17096@cbmvax.commodore.com> Date: 3 Jan 91 23:53:20 GMT References: <453@mathlab.math.ufl.EDU> <93075@aerospace.AERO.ORG> <86470@tut.cis.ohio-state.edu> <37299@cup.portal.com> <1991Jan01.211455.2825@ddsw1.MCS.COM> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Distribution: usa Organization: Commodore, West Chester, PA Lines: 91 In article <1991Jan01.211455.2825@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >In article <37299@cup.portal.com> mike_myke_schwartz@cup.portal.com writes: >Unix runs quite well in 4MB RAM and 80MB fixed disk, IF you have a >reasonable implementation of Unix! >If AmiUnix really requires something like 16MB RAM and a 1GB disk drive, >then it's seriously screwed up. Period. It certainly doesn't require that. But keep in mind, the only OS that's legally UNIX(TM), is a conforming version of SV.4, such as Amiga UNIX. That's a big puppy, no questions asked. You don't have to launch everything, just like you don't have to run everything under the SV.3.2 or whatever it is you run on your PC. But once you get X, NFS, etc. all going, 4 megs ain't quite what it used to be. If you just want a command line stand-alone UNIX, 4 megs is probably just dandy. We ran the SV.3.2 version on A2620s with 2 Megs of RAM -- you wanted four, but two worked. The two A3000/UNIX bundles they'll be selling are [a] 5MB RAM, 100 MB disk, and [b] 9MB RAM, 200 MB disk, Ethernet. >The problem with the SUN operating system space-wise is that it (and many >like it, the R3000 MIPS for example) is a RISC processor. That immediately >doubles the size of EVERYTHING the chip executes -- and incresed code size >equals both increased hard disk and RAM space. When you do less work per >instruction, you end up with a (much) larger program. Modern RISC systems hardly result in a 2:1 code expansion. While in some cases they do less work per instruction, I can't count many CISC processors that do 3 operand arithmetic operations, while most of the RISC machines do. You might find a typical RISC system taking 20% more code space, tops. Not that there aren't systems that eat memory, there certainly are, but the more common RISCs: MIPS, SPARC, 88k, etc. aren't all that more code space hungry than 680x0s or 80x86s. MISC machines, on the other hand, look to be extremely code space hungry. >2) Unix still has one of the best generalized IPC facilities sets that > has come along in operating systems (System 5 now). It CAN be > horrifyingly complex, but there isn't much I can't accomplish with > it. My experience with AmiDOS isn't nearly as complete here, > unfortunately. The Amiga principle here is "fast and simple". At the low level, you have signals and messages, which rely on shared memory. A signal simply indicates some agreed-upon event between tasks, a message passes some data between messages, by reference. UNIX message passing is much slower, and there are lots of different approaches, especially if you include BSD stuff in under the UNIX banner. What you get for the preformance price under UNIX is the ability to cleanly pass data between tasks on different processors, even across a network, using the same mechanisms used to pass messages between tasks on the same CPU/Computer. AmigaOS also has a standard inter application methodology, based on the AREXX language, which is currently missing from UNIX. >4) The utilities that come with Unix make it immediately useful to the > purchaser. While this is a market-driven thing, I haven't seen such > a rich "bundled" utility set in ANY other operating system on ANY > platform. This is very significant -- and Commodore could easily > address this with the Amiga line. The rich set of tools under UNIX comes from its tradition as a development environment. For years, folks bought UNIX, and relatively little other software, and used their computer to create new software. And you could pay a reasonable wad of green for UNIX. And most users were professionals if not experts, or had easy access to experts on-site. Most of the other operating systems in use were intended for a much more commercially active environment, in which all kinds of 3rd party software would be available and the basic OS should be available for reasonable prices, if not free with the computer system. The average person would need OS tools to get around, but this person would not be an expert, would be relatively alone with the system in a business or home, and wouldn't need a vast array of tools. Also, the included tools are rarely of the caliber of a dedicated 3rd party tool, but could easily stifle the growth of good 3rd party replacements if included. A good example is MacWrite on the Macintosh. Not bad, but not great world class word processor. Once Apple unbundled it, the Mac WP market exploded, and now there are all kinds of much better tools available. Large software companies can afford to specialize in one or two basic tools, and they'll do it far better than the OS vendor. If the OS vendor doesn't try to compete, the OS vendor and the 3rd party tool maker can cooperate, and both benefit. When that happens, the user will ultimately benefit. If the OS vendor tries to do it all, that vendor will fail, and very likely scare away the tool makers, who don't want to compete directly with the folks making all the OS decisions. >Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley