Xref: utzoo comp.unix.wizards:5994 comp.arch:3080
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!hao!oddjob!mimsy!aplcen!osiris!mjr
From: mjr@osiris.UUCP (Marcus J. Ranum)
Newsgroups: comp.unix.wizards,comp.arch
Subject: Re: Jerry Pournelle on UNIX (From BYTE)
Keywords: dig dis !
Message-ID: <1497@osiris.UUCP>
Date: 6 Jan 88 16:44:54 GMT
References: <1495@osiris.UUCP> <2126@haddock.ISC.COM>
Reply-To: mjr@osiris.UUCP (Marcus J. Ranum)
Organization: Institute For Felinographical Studies
Lines: 27


	There would be a few problems with making UNIX ROM-only - at least
the root file system: there are all the various files in /etc that do 
benefit from the occasional change.

	I also see making parts of UNIX (sh ?) in ROM as a bad idea since it
tends to greatly increase the development/repair/evolution time. If we had 
to unplug chips and bring an engineer in every time there is a PTF for a
part of a system, it would cost someone too much somewhere, and the changes
would never get made. I can cite the PC as an example...  As soon as you
start offloading parts of your software onto the hardware, you trade speed 
for flexibility.

	Suppose I create an intelligent disk controller with the UNIX fast file
system in the controller - suppose it hangs off the ethernet and understands
NFS so that it can be a "nodeless disk" or some such - now suppose NFS changes,
or there is a bug in my implementation. If I expect my customer to pay for my
engineer to come fix it - it'll never sell. If I expect to be able to afford
many upgrades, I'll be out of business in no time. The only places that can get
away with shenanigans like that are monsters like IBM - where they have such
a hold on their buying public that they can just say "pay for this, willya ?" 

--mjr();
-- 
------------------------------------------------------------------------------
...ich bin in einem dusenjet ins jahr 53 vor chr...ich lande im antiken Rom...
                     einige gladiatoren spielen scrabble...ich rieche PIZZA...